Update table fields

Hi All

When I update my application I sometimes add new fields to the back end data tables. It would then be nice to create a proceedure to update all my customers  databases existing tables with these new fields. As there are 50+ tables is there any way to run a routine that compares the field names in the old Data.mdb and adds any new fields that are now in the new Data.mdb.

I would also nee to get the current path name because sometimes the customers data tables are remote on a server.
Derek BrownMDAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
Many years ago there was a product called data angel that did this type of thing.    There was also something called BE updater, which is still floating around I think.

Two basic approaches:
1.  Working with tabledef object in DAO
2.  Using SQl ALTER statements (which many access developers don't use)

Current path of the db is a syscmd call,  but watch out; that's the current front end.    A quick way to get it is look at the connect property of a tabledef object for a linked table.

I use SQL Alter statements.  The BE contains a table that identifies its schema version.  I create an update that runs once (FE local table controls this) and trigger it from the login form of the FE.  It uses the update status in the FE table and the Schema version in the BE table to determine if the update should run.  When the stars align, the code first makes a backup and then the update runs and the two final steps are to update the schema version in the BE and the status table in the FE.  Of course, there is also error checking code to ensure that the BE is actually the correct version for the FE to prevent the FE from working if the BE hasn't been upgraded.

One decision I made early on was to never delete tables or columns.  They may become inactive but they don't get deleted.  So the schema change is always to add columns/tables or to add/delete RI.

Of course, there is always the possibility of a major design change that requires splitting a table or changing a unique index.  Those require significantly more testing because they move lots of data around and in the case of the unique index, the underlying data may have duplicates so you need to validate first and then do something to ensure uniqueness.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Derek BrownMDAuthor Commented:
Thank you both!

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.