Does VB.NET trash Access databases?

Question

Grasping at straws here... I work with a VB6 desktop system using several 2003-style Access databases (.MDB). Recently, I changed the first function from VB6 to VB.NET, still using an Access database. This is more than a conversion, but a rewrite with additional functionality. It is still fairly simple functionality, with a low-volume database. We have 1400 customers, small businesses with varying machine qualities. Most customers are happy with the new screen and functionality. A very few of those customers have experienced EXTREME slowness loading the datagridview. Customer Service tells us that 1) the machines have at least 1 GB of RAM, and 2) rebooting always solves the problem.

I wrote an app to severely slow down my machine, and it STILL runs better for me than it does for those few customers. Also, my Access database has never been trashed by this application.

Any suggestions?

Thanks!!

Poseidon

Sounds like you have a memory leak in your application. Are multiple users hitting the same access DB? – Vesuvianite

Both of those stores have multiple machines. Multiple means between 2 and 4. They would have the ability to be hitting the same DB, but not likely doing it frequently. Thanks for your help! – Poseidon

Answer 1

Rebooting while updating an access database can trash it.

You need some more info so that you have a better understanding of what is going on. They need to collect some information for you on a workstation that is having the problem. Using task manager you can have them get the following info:

• CPU utilization
• What task is consuming the most cpu
• Peak (committed) memory on XP - no equiv on Vista
• Total (committed) memory on XP - no equiv on Vista
• Available (physical) memory on XP - Free on Vista (made worthless by Superfetch)

It's also possible to use the command line tool "SYSTEMINFO" on both XP and Vista to get Total and Available memory. If you have very little available and on XP if your Total committed is larger than your Total Physical then you are most likely swapping and lack of memory (or a memory leak) is causing your slow down.

Bottom line is you need more information. It may be another app on the workstation is causing the problem. We had a situation where Notes 5.0 had a problem where if most of the window is covered up by another window and you received a new mail message the cpu utilization on Notes went to 100%. This caused apps to run slow and unless you are on the workstation looking at task monitor you would never guess it was Notes causing the problem. The problem was always called in on a different program (the one in the foreground). Access can also use 100% cpu in different modes even though it doesn't seem like it's doing anything.

Gather as much info as you can. You might want to write a vbscript or program that will will gather some info for you so that whomever is having the problem can run it to gather the info before rebooting.

A batch file that does the following will give you quite a bit of info:

@echo off
SystemInfo  >c:\systeminfo.log
tasklist /v >>c:\systeminfo.log

Carrasco

nice collection of hints - thanks! I'll see what kind of info they can already collect and start with your suggestions for more. – Poseidon

Answer 2

We have similar experience, the most cases are causes by antivirus. They check the file VERY often ( some antivures every access to file ).

Brainchild

AV should be turned off for MDBs if you are using file-extension-based scanning. There is but one instance of an actual in-the-wild Access virus ever, and if all you have is an MDB back end, there won't ever be any code run from that MDB anyway (as the users aren't opening it in Access). – Jobyna

Answer 3

No, VB.Net works great with Access. SHARED environments will trash access.

Since rebooting solves the problem I would check that you are closing your connections properly.

Trude

I don't think so. Need commonly use a access DB for 1-10 users on LAN. If the users does not use it very much, all works fine. But this behaviour is not "by default". Some experience with tweaking is required. But all information are available on internet. – Brainchild

Competent programmers have no difficulty writing multi-user apps using Jet databases for the data store. – Jobyna

Answer 4

Sounds like a big memory leak to me.

Some customers will leave your application running for longer than others, and will be harder hit.

Using Access where there are more than a few concurrent users inevitably results in pain.

Debus

Using Access with multiple users when you are incompetent programing applications against the Jet databgase engine sometimes results in pain. But it's the INCOMPETENCE that is the problem, not Access/Jet. – Jobyna

VB.NET (& VB6) don't leak memory. (You can "leak" database connections, though). – Palatal