>>>Another thing you might want to look at is the GenDBC program in the Tools\GenBDC under your main VFP directory. This will automatically allow you to programatically generate the DBC and it's views. The code it produces can be used and modified to fit your particular situation.
>>
>>Hey George,
>>
>>I just checked it out... Am I understanding correctly that I can, once I'm relatively satisfied with my database structure, store the generated code in my application and then just modify it and resend just the EXE as needed? Updating tables, views, data, etc.? Without disrupting the client data? That would be way too cool...
>>
>Renoir,
>
>In a word, yes. In fact, I use a similar strategy.

I think y'all have ignored something he said - updating tables and data. The code generated by GenDBC is great for updating the client when the only objects affected are indexes, relations, views and SPs.

Since he threw in tables and data after the original question, this is no longer totally true. He will have to modify the code for any table structure that changes. He will only be able to ALTER TABLE if there is to be no data loss or any other RI/indexing/PK loss.

I know SDT seems expensive for some, but when compared to how many billable hours it would have taken me to roll my own, SDT paid for itself with the deployment of my first VFP app. I rolled the cost of SDT into my first app. Now, SDT is virtually free in all my other apps. I also got a 10% discount because I was a PUTM.