>>>>>Help! Had a customer call in that the .dbc to our program was *missing*. Fixed it by hand with great cost of hair pulled, and thought that was the end of it. It's since reoccurred there once, and now with two other customers at separate locations...
>>>>>
>>>>>Is there an easy way to recreate a DBC from tables? What could be causing the DBC to disappear? The other database files (DCX and DCT) are still present, as well as an .FPT and .PAS. I'm about to suspect something in a backup or cleanup routine, but haven't had time to look into it yet.
>>>>>
>>>>>Chris.
>>>>
>>>>VFP ships with a utility program called Gendbc.prg. This will generate a program which can re-create a database.
>>>
>>>Gendbc will create a new blank database and tables. Not a good solution for an existing customer with data they want to keep. ;-)
>>>
>>>I had to run it on a different version and add in FREE TABLE, ADD TABLE and comment out CREATE TABLE, but was hoping for something quicker, easier, and more accurate.
>>>
>>>Chris.
>>
>>If you have another computer with exactly the same data structure. you can run gendbc to create a program which your customer can run to recreate the dbc. Having said that, I have never used a dbc myself, one of the reasons for this decision is the vulnerability which caused your problems.
>
>You don't have to abandon DBCs altogether -- just remember to have a facility in your program to be able to regenerate them if required (much like CDXs). GENDBC.PRG would be used to create an initial version of PRGs that you modify to make it "safe" so that it could be used with existing tables and not lose data.
>
>With regards to why DBCs may be disappearing -- it might not be the DBC itself, but perhaps the connected file -- namely the DCT or DCX files (if I'm not mistaken, they're basically like memo and compact index files). As these files are essentially memo files, they could suffer the old problem of "memo bloat" as well as "memo corruption" problems. Deleting the DCT and/or DCX file would render DBC unusable. Some operations that if used frequently enough may hasten crashing of DBCs:
>* frequently adding/removing temporary tables from DBCs (making sure your temporary tables are free tables would avoid much of this)
>* frequently calling DBSETPROP()
>* Performing a PACK (e.g. open the DBC as a DBF, then perform PACK) could be dangerous.

I know a dbc gives some advantages, but I never need any of them. These days I use MSSQL for all my storage.