AccessDataProvider

As part of the DAL Abstraction project I have promised a MS Access implementation.

Why Access you ask? Didn't Microsoft publicly say that Access is going to be phased out in favour of the more powerful MSDE?

Well it seems that our friends at Microsoft have backpedaled on this item. The first reason is because there is such a huge Access community ( think of the thousands of applications which use the Jet engine for data storage ). Secondly, the learning curve for MSDE is steeper in terms of installation, distribution, and deployment. Not to mention the lack of MSDE design tools. Last, but not least, Access is very cost effective for applications where there is not a large number of users or significant transaction volume. So it looks like Access is here to stay...

But I personally have not developed in Access for years. So the task of creating an Access Data Provider has its challenges. Given the fact that stored procedures have become the de facto standard for data access on the Microsoft SQL Server platform I was hoping I could apply these same concepts to Access. It turns out that Access does support stored procedures ( you have dig deep into the options to find the switch from ANSI SQL 89 to ANSI SQL 92 format but it does exist ). The thing I don't understand is that for all the SQL Server literature on stored procedures, there is almost nothing available for Access stored procedures. But my dislike for embedded SQL statements in applications far outweighs this dilemma so I forged ahead using my favorite development technique ( trial and error ) until my prototype worked successfully.

During this process I encountered an interesting quirk with OleDB. It seems that on the .NET Framework 1.0 ( VS.NET 2002 ) I could write logic which performed a Parameters.Clear method before returning the DataReader. The same code on .NET Framework 1.1 ( VS.NET 2003 ) would return an error "The connections current state is Open, Fetching". Weird stuff - luckily I found a reference on Mathew Reynolds .NET 247 or else I may still be bashing my head.

Since I am against writing mundane code, I adapted my SPROC Manager utility application to convert SQL Server stored procedures to Access stored procedures. This worked well in most cases but my latest issue relates to the T-SQL DECLARE statement and the lack of a corresponding construct in JET SQL. If anyone has any suggestions on this, I am all ears ( without local variables, procedures like AddPortalInfo are going to be tough ).