MS Access Application - Convert data storage from Access to SQL Server

Question

Bear in mind here, I am not an Access guru. I am proficient with SQL Server and .Net framework. Here is my situation:

A very large MS Access 2007 application was bui

Answer 1

You have a couple of options, the upsizing wizard does a decent(ish) job of moving structure and data from access to Sql. You can then setup linked tables so your application 'should' work pretty much as it does now. Unfortunately the Sql dialect used by Access is different from Sql Server, so if there are any 'raw sql' statements in the code they may need to be changed.

As you've linked to tables though all the other features of Access, the QBE, forms and so on should work as expected. That's the simplest and probably best approach.

Another way of approaching the issue would be to migrate the data as above, and then rather than using linked tables, make use of ADO from within access. That approach is kind of famaliar if you're used to other languages/dev environments, but it's the wrong approach. Access comes with loads of built in stuff that makes working with data really easy, if you go back to use ADO/Sql you then lose many of those benefits.

I suggest start on a small part of the application - non essential data, and migrate a few tables and see how it goes. Of course you back everything up first.

Good luck

Answer 2

Here is a technique I've heard one developer speak on. This is if you really want something like a Client-Server application.

1. Create .mdb/.mde frontend files distributed to each user (You'll see why).
2. For every table they need to perform an CRUD, have a local copy in the file in #1.
3. The forms stay linked to the local tables.
4. Write VBA code to handle the CRUD from the local tables to the SQL Server database.
5. Reports can be based off of temp tables created from the SQL Server (Won't be able to create temp tables in mde file I don't think).

Once you decide how you want to do this with a single form, it is not too difficult to apply the same technique to the rest. The nice thing about working with the form on a local table is you can keep a lot of the existing functionality as the existing application (Which is why they used and continue to use Access I hope). You just need to address getting data back and forth to the SQL Server.

You can continue to have linked tables, and then gradually phase them out with this technique as time and performance needs dictate.

Since each user has their own local file, they can work on their local copy of the data. Only the minimum required to do their task should ever be copied locally. Example: if they are updating a single record, the table would only have that record. When a user adds a new record, you would notice that the ID field for the record is Null, so an insert statement is needed.

I guess the local table acts like a dataset in .NET? I'm sure in some way this is an imperfect analogy.