views:

71

answers:

6

I have written a program in VB.NET and one of the things this program does is insert records into a Microsoft Access database. The backend of my program that access the database is written as an interchangeable layer. If I "swap" this layer out with a layer that used a Microsoft SQL Server database, my program flies. If I use MS Access, its still pretty quick, but it is much slower. Does anyone have any hints or tips on how to speed up ADO.NET transactions using Microsoft Access? I would really rather use MS Access over SQL Server so that I can distribute my database with my program (rather then connecting to some remote SQL Server). Any suggestions? Also, when I created the MS Access database, I created it in Access 2000 compatible mode. would it be faster to use 2003 compatible mode?

Thanks in advance

+1  A: 

Access is, as you're experiencing, less than optimal.

Have you taken a look at SQL Server Compact Edition. It can be embedded and distributed with your application...and should perform much better than Access.

Justin Niessner
Yeah, the only thing about it is, from what I've heard, is that it does not support stored procedures and I have a lot and it would be a hassle to convert.
Alan Bryan
How is Access less than optimal?
Tony Toews
Uh, does Access support stored procedures?
Jeremy McGee
Access is less than optimal because of performance. The query engine is slower than SQL Server Compact, you have to call Access through ODBC rather than native calls, file size is limited, and you don't get stored procedures (which isn't a huge issue to me, but still...
Justin Niessner
There is an OLEDB provider for Access which should be quicker ODBC. Jet is a nice engine nowadays, just don't expect it to handle millions of transactions or the same kind of data volumes that SQL Server will.
Simon
More critically, robustness can be an issue: if the power fails during an update, SQL Server will (usually) roll back or roll forwards so the database is in a known good state. While the JET engine is better than it once was it doesn't have the same reliability.
Jeremy McGee
If you're having performance issues with single-user Jet 4 back end, then you have application design issues. If you'd post the SQL for a particular operation that is slow, we could perhaps figure out the specific bottleneck there.
David-W-Fenton
A: 

SQL Server Compact 3.5 will give you the same benefit - a single database file that you can deploy and distribute (as long as you include the runtime assemblies in your app). It has reduced query capabilities compared to a full SQL Server instance, but it is definitely faster than the Access engine.

I have used it with a mobile app that has a desktop component and it did everything I needed it to do.

cdonner
Yeah, the only thing about it is, from what I've heard, is that it does not support stored procedures and I have a lot and it would be a hassle to convert.
Alan Bryan
Yes, it does not, indeed. If you have anything but simple joins and queries, I would not recommend it.
cdonner
Do you have some definitive speed test comparisons between SQL Server Compact and Access/Jet database file available?
Tony Toews
I don't, sorry.
cdonner
A: 

Did you also have the Access backend open in Access at the same time? If so try your program without having it open. If that speeds things up then you should open either a database connection or a recordset (against a table with few records) and leave it open while processing the data.

The problem is that if you open and close objects or recordsets against an Access database file and someone else is in the Access database file, Jet wastes a lot of time doing locks against the LDB file. So keeping a permaneent connection to the Access database file solves this problem.

Tony Toews
+1  A: 

Although you need to install it, SQL Server Express supports "XCopy file deployment" where all you need to do to deploy the application is ship an .mdf file and your executables.

Details are here on MSDN.

This does support stored procedures: I've used it in our unit tests to dynamically create a mocked-out database on the fly.

Jeremy McGee
A: 

To my experience, ADO.NET is not much optimized for MS Access. Using the older ADO or DAO interfaces (which are available in VB.NET via COM) can bring you performance improvements about a factor 20 or more in some cases. But it all depends a lot of what SQL statements your program really does (lots of batch updates / insert, or lots of queries with large result sets, or lots of interactive LOAD-Transform-Store Cycles).

Doc Brown
A: 

The MSDN features an Article on how to speed up ADO.NET: http://msdn.microsoft.com/en-us/library/ms998569.aspx Even though the article is a bit dusty, it still makes a few good points :)

Other than that, using MS Access myself, I found that a few techniques such as caching of data, selecting without the source scheme or optimizing queries are suitable to keep the performance at a halfway decent level.

Christian