Applications that are oblivious of the type of database (SQL or Access)

Hello Experts,

I need to write four applications in that are totally oblivious of what database is being uised; SQL or mdb (Access). What is the best approach? Are there any classes, modules or generic functions I can use?

Before you start telling me this is a bad approach, currently these four applications are written in VBA (mde) and using Access (mdb) as a back-end. We want to port the whole thing to SQL, but for various reasons it's just not feasible to do this in one big bang. We therefore opted for porting te applications one by one to, while still using the mdb-backend. Once all applications are ported we switch to SQL and start optimizing the applications for the new databse. This way the porting can be done gradually while minimizing the impact on our customers.

Any pointers, thoughts or suggestions are greatly appreciated.

Who is Participating?
cnjugunaConnect With a Mentor Commented:
I think creating apps that are not database-specific is actually a desirable quality and recommended.

Use ODBC that way as long as the datasource has the same name, the application does not have to deal with connecting specifications or anything of the sort.

*However*, note that not all SQL commands are available in different DBs. Syntax may also change for some commands depending on what DB you are using. It shouldn't be a problem with simple selects, inserts and updates especially if the DBs are Access and SQL server.
Scott McDaniel (Microsoft Access MVP - EE MVE )Connect With a Mentor Infotrakker SoftwareCommented:
IMO, using unbound controls in VB.NET is the first step. Use a data layer (i.e. a set of classes/modules etc where you interact with the database), and you can then code that data layer to take advantage of the various databases in use.

Note that while Access is _mostly_ ANSI compliant, it's not quite there yet. You may have to work with some IF constructs to properly manage data in an Access databse versus other platforms. For example, Access includes a Boolean datatype, whereas SQL Server does not, so you can just pass True or False to SQL Server, and if you pass 0 and 1 to an Access Boolean field, you'll end up with munged data. Also, Access expects Date values to be wrapped in hash marks ( # ), while other platforms will choke on this. You can use the standard single quote delimiters for this, of course, so just be aware of things of this nature.
The new generation of project management tools

With’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

dportasConnect With a Mentor Commented:
One of the potential problems is that the Jet database designs simply may not be suitable for SQL Server. In the MDB world you could encounter tables with missing keys or tables that are dependent on row order or the use of other aspects of Jet that don't easily translate to the SQL / relational world. So as a first step I'd suggest a design review and make sure your current databases are in Normal Form and that the logical design makes sense for SQL Server. If they aren't then you may want to do some refactoring even before you port them over so that you can support both systems during the parallel run.
Gustav BrockConnect With a Mentor CIOCommented:
Use the DataTableAdapters of Visual Studio. Or even the Entity Framework.

These let you program in VB.NET (or C# or ..) while the underlying SQL is generated automatically behind the scene.

altiplanoAuthor Commented:
So many options, so little time...
Thanks for the various answers, they were virtually all useful. Particularly some of the links CodeCruiser provided look like they give the answers I need.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.