I wrote a program running as a service that need to frequently gain access to MS Access database. After a period of time, my program exits automatically, then I open my MS Access database with Office, it says it is broken!
It seems very strange as my program do just some very common database access: insert, select and delete. Why is it always broken after running a period of time?
Has anyone here ever run into such problem? Any advice is appreciated.
Almost all problems of this nature when dealing with Access (or Excel, Outlook...) are due to not correctly releasing (i.e. cleaning up) resources.
Suggest you post any errors you are seeing.
Access does not recover gracefully if a program terminates without closing the database. There is a dirty flag that Access uses, and the repair feature will reset it (amongst other things), but typically, I don't recommend Access where any robust handling is required.
Related
I have an access database application, with many connections used to multiple external .accdb files. I have a number of things potentially slowing things down, and I'm trying to solidify the entirety.
The main thing I don't know at this time is how to find what code I'm using that is leveraging DDE instead of OLE, and how to update it to OLE instead (I assume that's the most modern implementation? Or is there something else I should use instead?).
I was cued onto my use of DDE as I got an error stating it was waiting on the DDE connection, which was opened successfully but still waiting on data.
Ideally, I'm looking for something that will convert well to SQL backend databases once I get around to setting those up, but for now I'm using the .accdb backends.
Thanks all!
I think Gustav's comment would help anyone else who happens upon my question.
For the purposes of this conversation, however, my tack has changed and I'm migrating to SQL backends now.
I migrated my classic asp site from IIS6 to a much powerful server with Windows Server 2008 R2 and IIS7.5, but it actually runs even slower.
Every simple call to the MSAccess database is taking forever. Many times the request is dropped because of Session timeout (120 seconds).
Any idea what can cause the problem and how to solve it?
Thank You.
Before blaming Access and moving to SQL Server Express or another database, you need to make sure you know where the slowdown occurs.
From what you are motioning, it looks like at least some of the queries don't even work (IIS times out after 120s).
Access databases, especially if they are accessed locally by a handful of concurrent users, are fast.
Moving to another database may or may not solve the problem, but it will be probably be a lot more work than solving your issue with your current Access database.
That said, if your website needs to server lots of concurrent users (say more than 50 at a time) you may need to look into moving to a full database server like MySQL, SQL Server Express or PostgreSQL for instance.
A few things to make sure you double check:
Corrupted database. Make sure you use Compact and Repair regularly as a regular maintenance measure (make a backup first).
Incorrect filesystem rights.
Make sure the your IIS process has read/write rights to the folder where the database is located so that it is able to create the lock file (.ldb or .laccdb depending on whether you are using .mdb or the new .accdb database format).
A related issue is that the IIS process must be able to create temporary files in the temporary folder, for instance %SystemDrive%\Windows\ServiceProfiles\NetworkService\AppData\Local\Temp.
Bad queries. Open the database with Access and run the queries to check how long they really take and if they return any errors.
If there are data integrity issues, it could be that the query returns unexpected results that could have strange side-effect to the code in your asp page.
Check your IIS logs for errors. Also check the OS Event Log.
Make sure there are no other errors that could incorrectly cause the behaviour.
Make sure you profile your asp code to find out exactly which queries and parts of your code are slow and which are fine.
Once you have solved your issues. Improve performance by keeping the database open to avoid the lock file being create/deleted all the time (this can have a huge impact on performance).
A good reference with more detailed information on some of the topics above: Using Classic ASP with Microsoft Access Databases on IIS
I am currently using VB6 to connect to a MS access DB using DAO and I’m experiencing a very noticeable speed reduction when a 2nd user connects to the Database.
Here are the steps to reproduce:
Open the Database from computer A by logging into the software
Add records to the database via the software (takes about .4 seconds)
A second user logs into the software (Computer B), ie: this opens the database, displays todays transactions, but the user does nothing else
On Computer A, repeat the operation of adding records, now the operation takes approximately 6 seconds
Further info…
the operation continues to take aprox 6 seconds, even after Computer B logs out of the software
if you close and reopen the application from Computer A the operation returns to taking only .4 seconds to execute!
Any help would be greatly appreciated!
Thanks!
That is the way MS Access works. While it kind of supports multiple users, and kind of supports placing the DB on a file share so multiple PCs can access it, it does neither really well. And if you are doing both (multi-user and over a network to a file share) then I feel for your pain.
The answer is to run the upgrade wizard and convert this to an MS SQL Server instance. MS SQL Server Express edition is a good choice to replace Acess in the case. Note that you can still keep all of your code and reports etc you have in Access, only the data needs to be moved.
Just to be clear on the differences, in MS Access when you read data from the database, all of the data required to perform your query is read from a file by your program, no server-side processing is done. If that data resides on a network, you are pulling that data across your network. If there are multiple users, you have an additional overhead of locking. Each users program/process effectively dialogs with the program/process of the other users via file I/O (writing lock info into the networked file or files). And if the network I/O times out or has other issues then those files can become corrupted.
In SQL Server, it is the SQL Server engine that manages the data requests and only returns the data required. It also manages the locks and can detect when a client has disconnected or timed out to clean up, which reduces issues caused by multiple users on a network.
We had this problem with our VB3 / Jet DB 2.5 application when we transitioned to using newer file servers.
The problem is "opportunistic locking" : http://support.microsoft.com/kb/296264?wa=wsignin1.0
Albert is probably describing the same thing ; the server will permit one client exclusive access of a file, but when another chimes in, this exclusive access will "thrash" between them, causing delays as the client with the oplock flushes all it's local cache to the server before the other client can access the file.
This may also be why you're getting good performance with one client - if it takes an oplock, it can cache all the data locally.
This can also cause some nasty corruption if one of your clients has a power failure or drops off the network, because this flushing of the local cache to the server can be interrupted.
You used to be able to disable this (on the client - so you need to service ALL the clients) on Windows 2000 and XP as per the article, but after Vista SP2 it seems to be impossible.
The comments about not using Access / JetDB as a multi-user database are essentially correct - it's not a good architectural choice, especially in light of the above. DAO is also an obsolete library, even in the obsolete VB6. ADODB is a better choice for VB6, and should allow you some measure of database independence depending on how your app is written.
Since as you pointed out you get decent performance with one user on the system, then obviously your application by nature is not pulling too much data over the network, and we can't blame network speed here.
In fact what is occurring is the windows file share system is switching from single file share mode into multi-share file mode. This switching file modes causes a significant delay. And this also means that the 2nd or more user has to attempt to figure out and setup locks on the file.
To remove this noticable delay simply at the start of your application open what we call a persistent connection. A persistent connection is simply something that forces the network connection to remain open at all times, and therefore this significant delay in switching between two file modes for file share is eliminated. You now find that performance with two users should be the same as one (assuming one user is idle and not increasing network load). So at application startup time, open a back end table to a global var and KEEP that table open at all times.
We are looking to have about 35-40 people writing to an access database via script on a shared drive. The metrics break down to them needed to write about 3-7 times an hour. Would Access support this without going ape on me.
Yes I would love to use this as a SQL server but that means going through massive amounts of red tape/meetings paperwork etc that I would prefer not to bother with
Could you not make them go with the free edition of SQL Server Express without the red tape?
In answer to your question, though, I've seen Access give big problems in environments with this many users, although that was pre 2007. I dunno how much it has changed.
If it were me, I'd avoid Access at all cost.
Could it? Yes. If you are very careful and perform locking and ensure that nobody steps on anybody else. Access is really not designed for any form of concurrency. I know of one place that managed to make it work in a very concurrent environment, but that environment basically logged everything and if the DB clobbered itself, it'd restore from the last backup and replay against the Access file automatically, so that the failures were transparent. I would not recommend following that course of action...
Should you do it? No. Is there any reason that you cannot use something like PostgreSQL or MySQL?
Yes, it would work. No, it's not a good idea.
Access would be able to handle the load, as long as those 35-40 people aren't all trying to access the database at once. It'll quickly bog down when you start having more than a couple of concurrent users, particularly if those users are all trying to update something.
The problem is that isn't not safe. You need to have the entire database file accessible on a network share, where any users will be able to write to it. You'll have multiple instances of Access trying to read and modify the file at the same time, and unless you are very careful with locking, it's quite possible for the database to become damaged or corrupt.
You'll also never be able to add any kind of access control beyond basic file permissions. You might not need it now, but internal databases often end up needing to be exposed to the wider world somehow.
It's not worth it. There are plenty of real RDBMS systems out there, for free, that are designed to handle this kind of thing. Why spend time trying to make Access work in such an environment, when you could just install SQL Server Express and be done with it? It has limitations, but if you're seriously considering Access, you're never going to be anywhere near those. Or use MySQL, PostgreSQL, Firebird...
I would avoid access too. Have you every thought about sql ce. It should handle multi users better and it is file just like access.
7 * 40 = 280 per hour.
280 / 60 = 4,6 per mins.
If your script is light, and if you don't read results too often, maybe...
Of course I don't recommand you to try. Meetings time! ;)
If the connections are opened only as long as needed to run the scripts, and you use transactions and have some retry logic built in when there's a conflict, there really oughtn't be too much of an issue.
If your script takes 1 second to do its update (that's a pretty long time in computer/database terms, of course), and there are 280 updates per hour, if you were lucky enough that no two users simultaneously ran their scripts, you would still have 3,320 seconds when the database was not open.
I don't see an issue, assuming that you know how to properly manage your connections and manage your Jet transactions.
That volume is not a problem for Access so long as it's on a stable LAN or very high speed WAN. Wireless connections are also a bad idea.
I have several clients which are adding about 200K to 300K transactions per year into the systems. So that's about 1000 per work day. That's using both an Access front end and back end.
That said one of them will be upsizing shortly to SQL Server. I fired the other client when they hired a PHB (Dilbert's pointy haired boss.)
It's iffy. The first time the database crashes you'll wish you went with SQL Server Express. And it will crash, eventually.
In my previous job we had a product with an Access database backend. We had some clients with 25 users. We refused clients who had 40 potential users because we knew from experience that the database would corrupt itself on a regular basis, and performance would be unacceptable.
The day we went to SQL Server Express, the performance of the application doubled, and the problems with crashing and corruption virtually disappeared.
I have a product designed to be a desktop product using MS Access file as a DB.
Now, some users need to install it in a few PCs (let's say 2 or 3) and SHARE the database.
I thought to place the MS Access file in a shared folder and access it from the PC, but... the JET Engine is designed for multiple user access?
Any tips or things to be aware of doing this?
EDIT:
The app is a .net one, using the database as storage (not using the database as frontend)
There is so much misinformation in the answers in this thread that I don't know where to start. I just spent 4 points in reputation voting down the answers with misleading and wrong information in them.
the Jet database engine (which is all that's involved here, as the OP clarified with an edit) is by default multi-user -- it was built from the ground up to be that way.
sharing a Jet data store is very reliable when the network is not substandard. This means not a WAN and not wireless, because the bandwidth has to be sufficient for Jet to maintain the LDB file (for multi-user locking), which means a ping by your local PC's instance of the Jet database engine once per second (with default settings), and because Jet can't recover from a dropped connection (which is quite common in a wireless environment).
the situation where Access falls down is when a front-end Access application MDB is shared (which is not the case for this poster). The reason it fails is because you're sharing things that can't be reliably shared and have no reason to be shared. Because of the way Access objects are stored in an MDB file (the entire Access project is stored in a single BLOB field in one record in one of the system tables), it's very prone to corruption if multiple users open it. In my estimation, sharing an Access front end (or an unsplit MDB with the tables and forms/reports/etc. all in one MDB) is the source for 99.99% of corruptions of Access/Jet files.
My basic answer to the OP's question is that, yes, Jet would be a great data store for an app of that size. However, if there's any possibility at all for the user population to grow above 25, then it might be better to start off from scratch with a database engine that is more robust at higher user populations.
It's perfectly feasible to do this; but you MUST split the database into a front end (with forms, queries, code) and a back end (data only). Every user has to have the front end on their own computer, linking to the shared back end.
It will be slow as Jet generates a ton of network traffic. Microsoft is also gradually deprecating Access as a development tool. Access 2007, for instance, has a far less sophisticated security model than Access 2003.
As a long time Access developer I am gradually moving away from Access.
Don't do it... the Jet database claims to be able to support multiple users, but it is incredibly easy to use the upsizing wizard to convert your Access file to a Sql Express database. That database file could EASILY become locked by a user or admin, and all of your users would be unable to use the database.
... and Sql Express is free. Your upgrade path from there to a full instance of Sql Server or some other commercial database is simple.
With 2 or 3 users on a reliable local network you should be fine, as long as you back the network drive up often.
Avoid any bit/bool fields in your tables - Jet has some nasty corruption issues with multiple access to them.
Also bear in mind that all locking in Access is optimistic: you will get dirty reads occasionally.
MS Access is designed for small office scenarios like this: non-critical light office use that you can set up with the minimum of programming.
Expect the data file to get corrupted every now and then - back up regularly.
The ACE/Jet engine is a great piece of software but, while it was designed to support multiple users, actually supporting multiple users in practise is not one of its strong points. The last straw for me is where then removed user level security (ULS) from the engine: I suppose I can imagine a simple database situation where all users will have the same privileges (i.e. admin access to all database objects) but IMO that is not supporting multiple users well, as compared with, say, MS SQL Server.
Yes, it supports access by multiple (that is, a small, workgroup-sized, number) of users over a network file share. However, the file share architecture is simply not ideal for supporting simultaneous writing to a file by multiple users. A client/server database system (SQL Server, etc.) generally provides better performance, security, and reliability.
As a sysadmin, please don't use Access for anything multi-user. Do what Jeff Fritz suggests and use a database that is designed for multi-user access. You may think that your little app is only going to be shared between a few people, but I guarantee you that it'll have a hundred users and fifty new features by the end of the year. And if those are all Access, rather than VB/SQL Express, your Ops people will break into your house one night and slit your throat.
Access isn't a client-server app, and provides very little in the way of backup/restore, or any automation whatsoever. Not to mention the interface and the DB are very tightly coupled... so if you ever want to turn this into a web app, or make any serious changes, your world will be filled with pain.
It's been done so many times by so many generic software engineers where we've seen a .mdb go corrupt in a multi user situation. If so many experienced specialist Access developers can get it right, as I'm inclined to believe, then we generalists must be doing something wrong and that something must be fairly fundamental yet non-obvious for so many of us to run away from the thing screaming 'Never again!' So if you consider yourself to be a experienced specialist Access developer (or you know how to find one) then go for it. But if you are a generalist or casual user looking for a lightweight back end then I suggest you look elsewhere (SQL Server is good IMO).
If your users can wait twice as long for an application with half of the features they want, then don't use Access.
Jet does not have the sophisticated lock logic required to support multi-user scenarios. You can get away with using it if your application is mostly reads and low-contention.
I've seen websites support many users, but I would recommend SQL Express unless you have a compelling reason to choose Jet.
I can tell you from painful experience that Jet 3/3.5 was not reliable. I saw it crash frequently under light load and when there were crashes you risked data corruption. It used to be extremely sensitive to any power problems, any client crashing against it (even the UI linked to the mdb), and any LAN problems. More recent versions of Jet might be better but switching to Sql Server is clearly the way to go in my opinion for anything other than trivial data entry with a small number of users. Sql Express is free and you don't really lose anything, especially if you're UI is in .Net, rather than Access.
EDIT: Microsoft doesn't think you should rely on Jet 4 either.
from: http://support.microsoft.com/kb/303528
Microsoft Jet is not intended for use with high-stress server applications, high-concurrency server applications, or 24 hours a day, seven days a week server applications. This includes server applications, such as Web applications, commerce applications, transactional applications, and messaging server applications. For these types of applications, the best solution is to switch to a true client/server-based database system, such as Microsoft Data Engine (MSDE) or Microsoft SQL Server. When you use Microsoft Jet in high-stress applications such as Microsoft Internet Information Server (IIS), you may experience any one of the following problems:
Database corruption
Stability issues, such as IIS crashing or locking up
Sudden failure or persistent failure of the driver to connect to a valid database that requires re-starting the IIS service
just check whether the db lock file (like .ldb) is there or not. If it is there, somebody is accessing that file. If it is not there, at present there is no one accessing that file and you may proceed. Otherwise, wait for when that file (.ldb) is no longer existing.
If you use a Terminal Server, the performance is real good. We have more solutions up to 50 Users at one Access mdb. Development is real fast and deployment easy.
Problems:
everybody can copy data mdb
no access rights
limited store procedures
optimize (compress and repair) only possible with no use data Database
limit to 2 GB!