Hi Paul!

I've been investigating a way to allow the user to backup without copying the DBC. I like your concept but alas, I can't seem to get it to work. I can copy tables that are non-DBC compliant, that is, where the field name lengths are ten or less. However, any tables that have longer names copy alright, but as you know, the field names get truncated and the CDX files that use those field names become corrupted, if they copy at all.

Is there some magic you are using here? If I specify the Backup copy of the DBC container in the COPY TO DATABASE clause, it tells me that the name is already used by the DBC, please choose another. Anyway, I'm about to go to back to the old "make sure everyone is off and try to lock the database container...method", but I thought I'd give you a shout to see if I missed something first.

As always, thanks for these great ideas...really shows your understanding of the problem!

Scott


>This might not help, but in a vertical market app I've been working on I wanted to give the users an easy way to backup the data (plus be able to schedule it from within the app) w/o either of us having to talk to their IT department. I created a directory called "Cache" in my main application directory. In it, I put a good copy of the DBC, a few default files, plus the Stonefield meta data. Inside of the application there is a menu option that they can select that will backup files. I've got an object that then makes sure the database is open, does a ADBOBJECTS against it, then walks through all of the files found. It opens the table, does a COPY TO into a backup directory, then closes it. When it's done, I call another method that zips up the directory for me (so they can easily send me a copy of the data; or, if I decide to, I can automate it).
>
>The idea is, I don't to make a backup of the DBC since I already have a good copy of it stored in the Cache directory. If I need to restore, I'll shutdown the app and launch the restoration process (which is another application). It will copy the files from the Cache directory and unzip the tables, then tell Stonefield to regenerate based on the metadata. This nice thing with this is that it automatically fixes those nasty problems when there is an issue with the DBC along with index problems in one step.
>
>But, if you really need to close everything, take a look at the CCustFrm::CDBManageForm for ideas on how to close and reopen everything.