Access to SQL Conversions


Free SQL Conversion Anaylsis
Anyone can upsize tables, but do you want to know what's REALLY involved with moving from Access to SQL?

We'll tell you exactly what is needed for your specific application, and how much it will cost. Email or ftp your current "mdb" file(s) to us, and we'll generate a detailed report of every conversion step.

Click here to email us your file(s) now. (or request ftp information, if files are too large).


When is it time to upsize?
If you are reading this, you are probably all too familiar with the Access "compact and repair" feature. In some cases, such data corruption is a result of sub-standard programming practices. However, even properly designed applications are subject to Access data corruption, especially when a large number of users are involved. Having your database go corrupt, even very rarely, is simply not acceptable. You can't afford to lose data, and there is no reason to operate with such worry. While Access is a phenomenal front-end database application, we feel it should not be used as a back-end storeage solution, for housing the mission-critical data, which drives your day-to-day business operations.

As if the concern over data integrity were not enough, there are other great reasons for upsizing you data to SQL Server. Your userbase may already be complaining about speed, weird errors, or workstations "hanging up". Typically, Access databases start to bog down around 1 GB, but poorly designed systems, or those heavy in data processing, can slow down much sooner than that. The solution to these issues is moving to SQL Server. This offloads all the actual work to the server, network traffic is greatly reduced, and your scalability becomes virtually limitless.


What is involved in the Conversion Process?
Access does have an "upsizing wizard", but this is really only useful for data-only conversion jobs, and even then is not recommended for mission-critical data. And, while your existing "front-end" (the forms and reports) will continue to be used, they must all be moved from the current "MDB" file, to a new "ADP" file (Access Data Project), where they can then be optimized for working directly with SQL Server.

It is true, you can leave the forms and reports in the MDB format, and simply "change the link" to SQL Server, but this approach layers the Jet database engine on top of SQL Server, so you realize no speed benefits (in fact, it's usually much slower), and you are no closer to having a true "client-server" application.

The typical SQL/ADP conversion process includes such steps as: converting tables to SQL, optimizing indexes, modifying relationships, creating triggers to enforce business rules, converting DAO code to ADO, converting Jet SQL syntax to T-SQL, converting client-intensive VB code to SQL stored procedures, implementing security, and re-working the existing Access front-end to interact with the new data source as efficiently as possible, in the client-server environment. Only in extreme cases is it desirable to create a totally new front-end database.