Updating/Appending Table Definitions

[xiong]

I have a task in front me. I have a fairly simple Access front end that links to a separate MDB containing the data tables.

What I am looking to do is create a table that houses table definition data

tlbName fldName fldType fldSize fldFormat

The goal will be to create a function that will poll through each table and check for changes / new fields and change the related tables accordingly.

I am doing this because it is a work in progress and I will be updating the live version about twice a week with a new front end. The goal is to automate the update so I won't need to manually make the changes to a number of different data sets (multiple instances)

Anyone have any thoughts?




"Only the educated are free.

 

[PHV]

Have a look here:

http://www.jrbarnett.freeserve.co.uk/mdbdoc.htm

Hope This Helps, PH.
FAQ219-2884
FAQ181-2886

 

[xiong]

That looks good for reporting on changes, but I don't see anything where it will actually make the changes to the tables if there are any.


"Only the educated are free.

 

[TheAceMan1]

How are ya xiong . . .

Not trying to sound demeaning but [blue]that many changes to even one table[/blue] is indicitive of the tables not being [blue]well thought out![/blue]

Not only that but as you say:

[blue]The goal will be to create a function that will poll through each table and check for changes / new fields and [purple]change the related tables accordingly.[/purple][/blue]

Your headed for trouble here (unless as I hope your very good). Resolve those tables first and save yourself the headache of all this . . .

[blue]Your Thoughts? . . .[/blue]

See Ya! . . . . . .

Be sure to see FAQ219-2884:

 

[xiong]

No doubt. Unfortunately even the best laid plans are subject to the wills of the clients.

These tables are already in production, and for reasons I'm still rather bummed about, I'm not going to be able to plan for the entire scope of the project in one sitting.

" We need it to do this now. Like right now! "

Heard that before?

Plus for my own use in moving a dB in testing over to a live production, might prove to be a bit more useful from time to time than importing all records from all tables to a new tabledef, then replacing the original set.


"Only the educated are free.