We have a ddl script (for each table) that creates the intial table. Any changes to that table are done as alter table commands in the script.

The script builder simply takes all of the ddl scripts and all of the stored proc scripts and creates a huge script file which it then executes.



>How does the script builder know of new columns or that they are metadata configured by you so you can populate them thru the script.
>
>Just curious. The DBA on this isn't the best. So I'm sure there's better methods.
>
>>Exactly the mechanism we use, except we have a script builder engine that takes all of our separate ddl scripts and stored proc scripts and creates one giant script from them which we run during our upgrade process. Has worked flawlessly now for about 5 years..
>>
>>
>>>I can tell you what happens at one of the projects I do now, Java/SQL. Whenver a developer makes a schema change to the database, they add to a script in Sourcesafe that contains any necessary changes.
>>>
>>>This script becomes part of the upgrade process. It will contain any alter statements necessary. For example, the last upgrade we did I needed to add a field to the state table that contained a code for IRS 1099 processing. So I created added to the script the alter statement to add the column, as well as the update statements to populate the column according the IRS 1099 document.
>>>
>>>>What process do you follow and how painless is it to update a client's sql express database (new fields, new tables, ...) as new versions of the app are released, similar to what Doug's Stonefield product does for VFP databases?
>>>>
>>>>>My point was (and is), that on a new project, I would not chose VFP tables as my backend DB, even for a small app. I'd use sql express. I used it twice last year and was happy with it. I'm disappointed with the provider for VFP, and I miss out on the t-sql '05 constructs that yield additional productivity.
>>>>>