Ed,

>Read the entire message next time.

I did.

>It was not meant to serve as a complete backup solution, but I guess a half screen of caveats just isn't enough to satisfy the people who fail to RT Full Message.

RT ?? What's that ? Are we beeing picky again today ?

>Actually, in case you've never tried, the following does work:
>
>CLOSE DATA ALL
>USE MyDatabase.DBC EXCLUSIVE
>COPY TO MyNewTargetDestinationWithADBCFileExtension.DBC WITH PRODUCTION

But won't create an exact copy to the database since a few headerbytes are not copied with the COPY TO command. IOW, You can't use the copy as a database directly.

>You have to ensure cross-table constraints and guarentee the integrity of the backup image, again, the sample code was not posted representing itself as a complete backup solution, but you have to read the message including the disclaimer found at the foot of the message. I realize that's expecting an inordinate degree of diligence to be shown when critically inspecting a message, but then I do make the foolish assumption that anyone reading the bug-ridden, maliciously created and sloppily created code that I leave lying around to trap the naive.

My dictionary won't help here. The gramatic is too complex for my limited knowledge about the amarican language. Since I assume that other foreigners could suffer from the same limitation, I draw the conclusion that it might be your way of writing messages which leads to confusion (no offense).

The point, however is that you asked what was wrong with your code. I replied to this question. No matter what the disclaimer at the end of the message reads, (though I have a hard time decrypting those american expressions of yours) it does not change the question. Let's not quarell about this issue and stick to the subject. Please let us be constructive.

>BTW, the option of opening the target tables and appending the current table content into the backup rather than COPY operations hasn't been explored; for any non-recursive database schema, it's possible to construct a digraph that describes an order of populating the tables in the schema so that the data tables will be able to enforce all RI rules, and in the event that there is recursion, the temporary removal and subsequent reestablishment of one relational link of the recursion loop should allowthe sequnetial repopulation of the tables forming the recursion, and after the data participating in the relation is appended, the integrity fo the database is checkable and reestablishable if valid.

I'm not sure what you are trying to say here. Do you mean that by ordering the COPY TO statements you'll avoid RI problems when changes are made during the execution of this command ? This might work, however parent tables should remain locked while updating childtables because in when copying child1, the parent table could (for example) do a cascading update wich affects child2 which still has to be copied, breaking RI with the copied parent. Again this strategy might hurt concurrency. However I agree there can be some optimizing in such way that not all tables are locked during the whole backup operation. Besides this, FLOCKing a table still is better than requiring or forcing (disconnecting other users) exclusive access.

>I posted a code fragment to suggest a different approach to backing up the data in DBF tables; I'm just waiting to see what sort of significantly better source to help the person who originally asked about the COPY FILE issue; I'll be happy to review the risks associated with using the CopyFile() API for the backup process if you like, which fails to try to ensure that the content of an individual file remains consistent through the life of the copy, or that the file copy started from a stable state of content; maybe you overlook the fact that I know how CopyFile() and SHFileOperation() manage contention while copying a file shared with active VFP apps.

Hmmm, I overlooked the fact that you know how these kind of API's work? No, not even I'm THAT ignorant.

>I know that given time and desire, I could write a better implementation of delivering reliable and consistant VFP-administered data archiving, bit that's not an item that feels compelling to explore at the moment. Since you take issue with the strategy I proposed, it should be relatively easy for you to demonstrate the right
>starting point for the curious reader to implement...

In fact I already gave a possible solution in my reply to you (who was saying something about reading the whole message ? ;-)). You can open all tables, lock them all (watch out for deadlocks) and use the CopyFile API to make a copy of the database. The only thing I'm not sure about is that if a filelock is hold onto a table all data is flushed to the file (for example in case of SMB's oplocking mechanism). In my opinion that is the only thing that might cause the solution not to work, but then again, solutions will be found to work arround this problem too.

Walter,