BackEnd on SQL Server

LadyDi

Registered User.
Local time
Today, 11:47
Joined
Mar 29, 2007
Messages
894
I have a couple databases that were created a just a month or two ago, and are already over 1 million records. As a result, the databases are really slowing down. I read somewhere that you can house the backend of a large Access database on an SQL Server. I was just wondering what steps I would need to take to split these databases and move the tables from an existing database to an SQL server. Also, these databases have programming in them that allow them to go out to spreadsheets, collect data, and store that data in the tables. What would happen with that programming if the tables were housed on an SQL server. Would they still work? I was also wondering if you think that would be the best thing to do to speed up a very large database (over 100 MB). Any advice or assistance you can provide would be greatly appreciated.
 
Switching to an SQL backend should definitely help speed things up. I've personally found a large performance gain even when my database was only 5MB. And the effect becomes greater as the size of the database grows. There are a few options to migrate from an Access backend to an MS SQL backend. Before you start though, make sure all your tables have a primary key and back up your database.

The most obvious option is built right into Access, known as the Upsizing Wizard. It's probably also one of the easier options. You can easily find tutorials on it on Microsoft's website, or you can just try it out yourself.

Another option many people prefer is using SQL server to import. For this, you need to have SQL server installed as well as SQL Server Management Studio (SSMS). Create a database using SSMS, then import the Access database into the new database. You will have to reconnect the tables to your Access application manually. But, the database conversion on SQL server is usually better than what you get from Access.

If you decide to opt for another database rather than MS SQL, for example MySQL, conversion might be a bit more difficult. One of the easier options to do without any programming experience is to export your Access tables into another format that can be brought into MySQL (or whatever database you choose). For example, you might choose to export your tables as text or Excel tables, then import them into MySQL. You will have to redo a lot of the table structure though, such as primary key, data types and relationships. Although, even if you use MS SQL, you should still double-check those things migrated correctly as it still doesn't work the same way as Access.

As for the programming, all of the code should be in the frontend. Therefore, you may not have to change much if anything at all. Personally, I have only had to add a dbSeeChanges option to DAO recordset creation.
 
Simply converting a Jet/ACE database with this many rows to SQL server is just as likely to increase the time it takes to fetch rows as to decrease it. To take advantage of a server-side database engine, you may need to change the way your forms work. Make sure your forms are bound to queries that include seletion criteria to reduce the number of rows and columns requested from the server. If your forms are bound to tables or to queries without criteria, SQL Server will be forced to send over the million rows every time you open the form. This will not be a pretty sight.
 

Users who are viewing this thread

Back
Top Bottom