I have an Access 2003 database using MS-JET linked tables (that is, there are two *.mdb files). The overall task is to move to SQL server. However the existing databases have multiple fields with spaces and other characters that upset both of the Access migration wizards. So the intermediate task is to make a version of the existing mdb’s with updated field names.
“Simply” changing field names in the UI mdb file doesn’t work, because of the linked tables being read-only in that mdb. Updating the Data mdb file field names first doesn’t work because the UI mdb then throws a wobbly on startup and Access gives up.
I’m looking for suggestions, but options I can see are:
-
re-integrate the Data mdb back into the UI one, do the updates, then re-export the data. Seems very risky to me (system is live, don’t want to play with data any more than strictly necessary).
-
I’ve looked at several answers here relating to changing ODBC details with VBA code, which is interesting, and I can see how I might be able to programmatically edit the linked tables’ names. Is this going to work? Is there a better way?
-
Unlink all linked tables, then edit in UI mdb the remaining forms, reports, queries (but would that work??) and edit the Data mdb fields, and finally relink everything. Will it fall apart?? … seems likely.
Any suggestions?
Ruth
See what track name autocorrect offers. How Name AutoCorrect Works in Microsoft Access
Make a copy of your UI MDB, delete the linked tables, then import them (as tables rather than links) from the Data MDB. Once you enable autocorrect, Access will attempt to propagate your field name changes wherever they are used (in forms for example). Unlikely it will catch 100% of the necessary changes, but it should resolve a big chunk of them. You would then need to manually track down and fix the rest.
Once you have everything fixed, you could use that MDB version to “upsize” your tables to SQL Server. However, one huge complication is if the original database is “live” while you’re making changes to the new version. If you absolutely can’t take the database out of service in the interim, you could discard the data from the new tables, then use “append” queries which alias the old to new field names to pull in the latest data.
Finally, a warning about autocorrect: do not leave it enabled in the production version of your database because strange things can happen. The safest approach IMO is to turn it on, complete your object name changes, then turn it back off again.