>Ed,
>
>>If you're working with DBFs making backups from within a VFP app, what's wrong with something like:
>
>The problem with the VFP aproach is that this will create standalone tables with the loss of long (field)names, triggers, validations and other database properties. Also copying a database file can't be done with a USE and COPY TO statement.
>
>The easiest way to manage these problem is by simple copying the table via a Copyfile API or something equivalent.
>

Read the entire message next time. 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. It acts to pull the data across in a consistent and reproducible fashion; if you need to maintain the relationship to the DBF, not just the data, you can always recreate the database programmatically using SDT or code emitted from using GenDBC or a similar tool and append in the data from the backup images into the newly created DBC and tables, but I guess that's too difficult a solution to consider. I'm well aware of the limitations of various file backup products, having used ArcServe's enhanced services for backup of opened files, but while it guarentees that the file snapshot reflects the table at the start of the backup for the table, it can't guarentee the state of deferred writes to the DBF pending at workstations in the same fashion that FLOCK() will do.

Actually, in case you've never tried, the following does work:

CLOSE DATA ALL
USE MyDatabase.DBC EXCLUSIVE
COPY TO MyNewTargetDestinationWithADBCFileExtension.DBC WITH PRODUCTION

>Holding a file lock on the table will prevent intermediate updates on the table while copying but you'll not prevent corruption of cross table constraints like Referential Integrity. A solution might be to open all tables at forehand, FLOCK() all of them and copy the whole database. Practically this will seriously hurt concurrency because no updates are allowed in any table while copying the whole database.
>

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.

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.

Once all tables are populated, views may be reestablished, since the relationships between tables is intact after copying the data.

IOW, given an understanding of the physical data model and the relational topology of the graph depicting the interrelation of tables, with tables as nodes and relations as vectors between nodes, it's possible to retain the DBC structure; alternatively, it's possible to recreate the DBC and it's tables and populate them from free tables that reflect a consistent state snapshot of the state of the data. If you've saved the data and can recreate the long field names, triggers, validations, views indexes, SPs including RI in code, then the reliable data and the reliable code to recreate the DBC preserves everything, reduces the complexity of the backup, including the need to save the CDXs and IDXs which can be recreated with code should restoring from a backup be needed is all there. Ensuring that the data is stable andreflects a fully consistent state removes the complex isses of retaining the DBC attributes during backup.

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. 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...

IOW, "Where's the beef?"

>If really wanting the ability to have online backups you are far better of with a commercial RDMS product like Oracle.
>
>Walter,