X# slow - maybe the array handling ?

[ic2]

I am happy to hear that too. Currently DBF handling and editor speeds are IMO the most urgent issues while so much else is working very well so it's good it has your full attention.

But these 2 issues are for most users the most important.

Dick

[robert]

Dick,

I do not agree that DBF speed is for most users the most important.
Many, many users have switched away from DBF to client server solutions using either Advantage or one of the SQL solutions available.

In a networked environment DBF based solutions are no longer recommended anymore because of all the SMB caching issues which force you to tweak registry settings.

This does not mean that we will not look at this though.

Robert

[ic2]

Hello Robert,

We use ADS too, as do almost all our clients. But as Wolfgang also indicates, ADS with X# also has some speed issues. So in a broader sense:

DBF/ADS & using X# in VS are (IMO) the most important issues. If that works flawlessly, speed & functionality, everything else X# can do above VO is (for us) "nice to have", at most.

And I do realize very well how hard you are working on it. Therefore I keep renewing our Fox programs despite we still use very little of X# and most of the (admittedly elaborate) functionality which has been and will be added.

Dick

[wriedmann]

Hi Dick,
please let me confirm that the speed issues that ADS sometimes has have nothing to do with X#, but they are also occurring when using VO.
Nevertheless we need also the DBF access in networks because we have many customers we cannot switch over to ADS (even if I would like to do, but currently it seems X# will have a longer life than ADS).
Wolfgang

[ic2]

Hello Wofgang,

We also had issues (cdx files got corrupted) using our X# app in a CGI environment (obviously without ADS). These may be solved by now but as it needed to get solved (it was in a production environment) we moved back to the Vulcan DLL's and now it works without problems. That's what I mean with that in general I consider DBFCDX/ADS + the VS integration so important.

Note that you can also use the ADS local server for users who do not (want to buy) the ADS Remote Server. Officially no more than 5 simultaneous users are supported but from experience I know that it works for more.

Dick

[wriedmann]

Hi Dick,
the ADS Local Server also does not works on a remote desktop session.
I have also a license for the Apollo Driver, but have yet to test it on a database shared with VO.
Wolfgang

[ic2]

Hello Wolfgang,

,
the ADS Local Server also does not works on a remote desktop session.

It surely does. In the ADS.ini you have to add:

MTIER_LOCAL_CONNECTIONS=1

It turned out to work when we were unable to find out why ADS Remote server wasn't recognized on an unusual server configuration which was setup by a dealer after disk space expansion extremely slowed down program execution.

This is supposed to be a test only statement but without decent support of SAP we had to try that and it did actually allow that client of ours continue working on their RD, with local server.

Dick

[mainhatten]

Robert,

FoxPro seems to simply assume nothing has changed and shows "old data" even when another user has changed the data in the mean time.
It waits until you try to update the data before checking for changes made by other users.
And after a timeout (SET REFRESH TO) it refreshes the local caches of the data.

In vfp the idea of local caching of "remote" (might just be ISAM-accessed dbf on file server) persistance-needing data was born when 10MB nets and ISDN online speeds were common here
Combined with Rushmore optimizing most data accesses a lot best practices oriented on buffering, (usually optimistic) locking strategy, conflict resolution options and chances to look at needed time with curval(). The mindset on shared table handling was that of a SQL backend data store.

One of the things that has a negative impact on the speed, even in exclusive mode, is that the data inside DBF files is always Ansi and we have to convert it to Unicode.

Compared to ANSI runtimes like vfp or VO this is more effort. OTOH doubling char field sizes to store 2Byte "chars" would make transfer from disk to memory slower.

A positive side effect of the changes that we did is that we can now also access DBF files larger than 2 Gb.
Unfortunately that may cause problems with shared access since the locking scheme then overlaps with the record contents.
We will add a (configurable) option to switch to Harbour locking scheme for large files when your DBF exceeds the 2 Gb.

ADS also has the option to use tables beyond 2GB and implements a different locking schema on those tables. Have you compared Harbour and ADS locking method ? If they are different, ADS-opened large tables should not be written into from xSharp...

regards
thomas

[mainhatten]

However...
There is a 4 byte field in the DBF header (DBASE_LAN, only used by Dbase AFAIK) that we could use for a version counter:
https://github.com/X-Sharp/XSharpPublic ... er.prg#L31
We may be able to increment this field for every update to a DBF, so other stations can see that the file was updated.
That means that this page from the DBF should never be cached but all the other pages could be cached, as long as the version number in this location is unchanged.

If working reliably this could short-circuit CursorRefresh calls if vfp. But on heavy used tables a 4Byte integer might overflow and any schema to reset might have trouble with cursors explicitly set offline (unless they get special treatment in "Use Online")
Also concurrent use with VO or vfp, which will not set that counter, must be prohibited - new dbf type set in header?

regards
thomas

[mainhatten]

Hi Wolfgang,

please let me confirm that the speed issues that ADS sometimes has have nothing to do with X#, but they are also occurring when using VO.

No code seen so no idea what might happen - but I think the MS ideas on disconnected result sets, buffering, locking strategies and where clause construction for update were great. You can find the vfp help file for download on vfpX - if you have not done already, read the parts on buffering, locking and updating views (which is identical to the later introduced Cursoradapters). You can also check on update strategies in Dotnet ADO.Net Datasets and Datatables - same options for where, only not as a single ENUM with 4 values but 2 properties IIRC. Godd stuff to ponder if you have not checked already.

Nevertheless we need also the DBF access in networks because we have many customers we cannot switch over to ADS (even if I would like to do, but currently it seems X# will have a longer life than ADS).

As long as it works, calling it dead is premature - vfp got no maintainance and is still "alive"

regards
thomas