Question Converting to Access 2007
- Thread starter Tallbloke
- Start date
- Local time
- Yesterday, 16:18
- Joined
- Aug 30, 2003
- Messages
- 36,270
I've converted a number of 2000 db's with no major issues. Sometimes goofy little things like reports that displayed perfectly suddenly need a textbox or two widened because they're displaying #####. Same printer, so I assume 2007 renders slightly differently than 2000 did. I don't think you'll have any big issues.
I've only ever had a problem if having to go backward when working on a different machine (because why else would you back-step?) But Trevor G makes a good point - make sure you know all of the links and VBA to ensure everything is still active.
I would back up somewhere seperate from the newly updated machine. That way if anything does go wonky - you have an unsullied copy of the DB to fall back on.
I would back up somewhere seperate from the newly updated machine. That way if anything does go wonky - you have an unsullied copy of the DB to fall back on.
Thinking some more about it, I'm not sure there is much need, everything works just fine and the changes I am making aren't huge.
That said, I am working on a separate copy of the front and back ends of the database. I know I can just copy over the front end on user machines and everything will be fine. What I was wondering is if there is a way to copy a new table structure without over writing or losing date. I'm sure there is, but it's not something I want to mess up without double and triple checking
And it goes without saying I will be backing up everything before I make any live changes
That said, I am working on a separate copy of the front and back ends of the database. I know I can just copy over the front end on user machines and everything will be fine. What I was wondering is if there is a way to copy a new table structure without over writing or losing date. I'm sure there is, but it's not something I want to mess up without double and triple checking
And it goes without saying I will be backing up everything before I make any live changes
- Local time
- Yesterday, 19:18
- Joined
- Feb 19, 2002
- Messages
- 47,029
Changing the schema on a production database is problematic. There are great tools available for SQL server to compare one database to another and generate the necessary DDL to equalize the schemas. There are none for Access. So, what I do is upsize my from and to BE's to SQL Server and run the tool to generate the DDL. I then edit it (mostly you need to change "." to "_" in the table names) to make it ACE compatable. Then I run the DDL against the "old" production schema, upsize that version and compare again to make sure all the changes have been applied.
Of course, this is all a lot of work but necessary if you have many changes. For small changes, I just write the DDL myself as I go along. Then unless the changes were trivial, to validate my work I upsize and compare.
If your changes involve splitting or combining tables, you will also need to create queries to handle the data transformation.
Before you make your final changes to the production BE, you must back it up. Two is not too many backups. Three is better. To make schema changes, all users must be out of the database. I normally do schema changes after normal business hours or on weekends so I don't impact daily work.
Of course, this is all a lot of work but necessary if you have many changes. For small changes, I just write the DDL myself as I go along. Then unless the changes were trivial, to validate my work I upsize and compare.
If your changes involve splitting or combining tables, you will also need to create queries to handle the data transformation.
Before you make your final changes to the production BE, you must back it up. Two is not too many backups. Three is better. To make schema changes, all users must be out of the database. I normally do schema changes after normal business hours or on weekends so I don't impact daily work.
