I need to automate the migration from an Access (2003) to an SQL Server DB (2005 or 2008). The upsizing should be done automatically as part of a build process.
I need that because there are 2 versions of the software, a single user rich client and a web version. Access DB is used for single user to minimize setup effort, SQL Server to improve performance and scaling with many simultanious users. Access should be the “leading” DB, meaning devs do changes in Access DB and those are propagated to the SQL server within the build process. Many changes will occur, so doing it manually is not an option.
I am new to the Microsoft world, so I dont know appropriate tools for that. What tools can I use and how? I know how to do it (by clicking) with the upsizing assistant. Perhaps I can automate that somehow?
Thanks in advance for your answers.
Cheers,
Arne
The problem here is that you trying to do versing with two different systems.
If all of the design changes can be done in Access, then you can simply up-size that to sql server. The problem here is do you need to modify the existing sql server databases? And, do you need this over time? Upsizing the access database will get the new version up to sql server, but it WILL NOT help for existing sql server databases.
If you need over time to have changes to tables on BOTH systems and existing systems then I would state to the access developers that ALL changes to the tables MUST be written as ddl sql. You then use the ddl executed on Access to make the changes. The developer MUST THEN AT THAT POINT take that same ddl and run it on the sql side. It might need slight modifications. They fix it to run on sql server. So, then you wind up with two scripts. One for sql server, and one for Access. In the case of access you can write a few lines of code to read and process a text file of ddl. (that same code can be used for all scripts).
That way, you build up a equivalent set of changes for each upgrade. So, simply NEVER allow design changes direct to the access tables. If you allow design changes with the table designer then you are in big trouble as you don’t now know what changes need to be carried over to sql server.
However, as better recommend approach I would suggest that table desing changes are done FIRST in sql server. The reason is the table designer in sql visual studio tools allow the changes just made to be scripted to the clipboard (a simple right click). The other reason is that the table designer is VERY much like the access one. So, this is easy even for access developers with little sql server experience to use. So, that simple right click of “script changes to clip board” would create the need change script for sql server (they would save this into a file for sql server). They then take the ddl, and run it on the access side. The reason for this is the ddl might need some slight mods for Access (but, they did not have to write the ddl statement). So, this means the ddl gets written for them. This means you know the sql server ddl is correct. They then simply take that ddl and use again to change the access table also. The ddl might need slight changes for access, but that’s just fine because they need the table change and then run and fix this untill the simple table change is made. So this scripted ddl would be then saved for the access update into a file also. The ddl script might need slight modifications for access so I think this approach is best. As long as this is being changed/fixed as they go along you be fine.
So over a period of changes, you wind up with two scripts that keep the changes in sync for both systems.
If you don’t need changes to existing sql and access databases, then just let the access folks have at it, and then simply up size the whole database to sql server in one shot and you done.
I can’t really think much of any other approach between the above two extremes.
You could have the users make the change in access and then go to sql server to make the change in the sql table design and then save the sql server change script. However, this would not get you a change script for the access side. If a change script is NOT needed for access side then this would work very well as you would get a sql server change script.
The above would be how I go about this and it quite workable…