Update speed xdot

[omni]

Roger,

About once a month at some of our larger sites a file will become damaged, usually due to a file write error. The index is bad, and the file can be read using xdot, but foxpro, the driver we use, will not read it. We have to use a backup file (foxpro initiated), empty it, and append to it using xdot, then reindex it with foxpro.
We like to continue to use foxpro for our support team to be able to manipulate data and write quick fixes or queries in foxpro..its just faster.

The problem is the time it takes to append 200-500,000 records from the one file to the other. No index when this is done. If its foxpro, takes a couple of minutes. In xdot, a couple of hours, or longer.

is there a solution to this, or do we just have to live with it? We have a similar problem with reindexing, where xbase takes much longer.

As always, Thanks

Fred Henck
Omni

[rdonnay]

I highly recommend taking a more serious look at Advantage Server.

If you can commit to this, then I will show you many ways to accomplish what you want.

Firstly, your files will not become damaged.

Secondly, if by some rare event, a file must be updated, or a structure updated, this will occur 100 x faster.

[omni]

Roger,

we used that for a few years, but did not see any benefit. Actually never had any reason to believe it was doing anything. The only difference was that the users speed was dramatically reduced, especially when opening the app. Most of our clients have less than 10 users, and none of them want to pay for a client server unless I can sell them on a good reason. We have never had a database completely corrupted, only indexes on file write errors. At times, when these indexes are damaged, the file is not readable in foxpro, but we can open it in xdot to transfer it. It just takes a long time to do this.

Fred

[Tom]

Hi, Fred.

I'm not sure I really understand what you are saying, but this is my interpretation: If an index file is damaged, you restore the table (!) using a very uncomfortable mechanism - and then reindex the restored table? Is that correct?

[rdonnay]

The reason why the COPY TO command is much slower in XDOT is because of the progress bar.

I would need to add a clause to DC_DbExport() to tell it not to use the progress bar.
Please remind me again after Feb 1 if you don't hear from me before then because I am travelling this month.

[omni]

Actually, its the append from, but it is probably the same issue.

[rdonnay]

yes, it is the same issue.

[rdonnay]

Here it is:

Copy _DCAREA.PRG to your \exp19\source\dclip1 folder then run BUILD19_SL1.BAT or BUILD19.BAT to rebuild your DCLIP1.DLL.

Copy DCSTD.CH to your \exp19\include folder.

Run XDOT.EXE.

The APPEND FROM and COPY TO commands now support a NOPROGRESS clause.