A few questions on MS Access databases -
Size: Are there limits to the size of an access database? The reason i ask is that we have an access database that has a few simple tables. The size of the db is about 1GB. When I do a query on it, i see it taking over 10 minutes to run.
With proper indexing, should MS Access be able to handle this or are there fundamental limitations to the technology.
This is MS Access XP.
Also, does MS Access support db transactions, commit and rollback?
You will get many varied answers here, but in MY OPINION access is just not there as a scalable solution. It doesn't handle multi-user situations very well, as you start to approach 1Gb in size, stability starts to become a MAJOR concern, and in reality it just doesn't have the performance.
In regards to transaction support, please see this Microsoft Article.
Also, here is a article that actually points out a good majority of limitations of access.
Personally, I've found the 'usable' limit to be in the couple hundred megabyte range.
Access is designed and meant for small databases. For large ones, ie ones beyond just something you and a couple-few people are using, you should be looking at a "real" RDBMS like SQL Server, ORacle, DB2, MySQL, etc.
EDIT - see http://www.blueclaw-db.com/vb_transaction_processing.htm for a way to handle transactions with Access. Apparently it's not native.
The maximum size of an Access database is 2GB. You can get around this by using linked tables in other files, but it's probably time to use a more robust database if you are already experiencing performance issues.
My recommendation would be to look at SQL Server Compact, which is a no-cost, file-based database or, better yet, SQL Server Express, which is a no-cost, "lite" version of SQL Server that will support multiple users and interoperability with SQL Server. Both limit you to 4GB databases.
All of the products mentioned, including Access, support transactions.
In answer -
Size: The maximum size of an Access database is 2GB.
Transactions: Transactions are fully supported by the underlying JET database engine.
From past experience I'm inclined to say that you're probably hitting the maximum usable size and should maybe consider upsizing to SQL Server Express.
I'm not sure if they are still there in the XP version, but in Access 97, there were compact and repair options. If these are still options, they may help.
While this is going back many years at a time when the cost of entry into a SQL Server installation was as prohibitive as Oracle, one of my clients was using Access to try to manage an inbound call center.
We are talking about VLDB-very large database concepts 40 million rows. This was during the era of telephone companies rolling out caller id and offering their subscribers a way to receive a free caller id device. Because of cost contraints they had to ignore my pleas to make the SQL Server investment.
In practice it seemed that Access toppled at about 800MB. We partitioned tables into multiple Access databases to handle the load. Believe it or not, it worked beautifully. The client was grateful.
In practice given the availability of the SQL Express, I too would recommend going that route.
My impression from reading the Access newsgroups over the years is that ACE/Jet engine (.accdb, .mdb or .mde file) is only recommended nowadays when using MS Access as a RAD forms-based development environment using bound forms. If you don't have an Access front end then there are few arguments in favour of a ACE/Jet back end when considering the much more scalable (and capable) alternatives: SQL Server Express or SQL Server Compact Edition for MS shops, MySQL, etc.
As reagrds transaction support in the ACE/Jet engine, yes it is present and native. Another answer linked to an article about using transactions via DAO: note that many aspects of DAO are limited because its development lags that of the engine and transactions is one example. Happily, you can use SQL DCL: BEGIN TRANSACTION, COMMIT TRANSACTION, ROLLBACK TRANSACTION, etc to acomplish things not possible with DAO e.g. nested transactions. SQL DCL requires the Access interface to be in ANSI-92 Query Mode; using ADO will work because ADO uses this mode natively. For more details, see:
Jet can be a very good data store for any number of desktop development platforms, not just with Access itself. It's always been a first choice for VB developers and still is (for good reason).
A 1GB MDB that is not expected to grow a lot ought not be a problem in terms of speed or reliability. If it's slow, then you haven't indexed it right, or you're writing very inefficient SQL. An example of inefficient SQL would be applying WHERE clauses to expressions, which therefore can't use indexes -- an example would be
WHERE Year([MyTable].[MyDate]) = 2002
as opposed to
WHERE MyTable.MyDate Between #1/1/2002# And #12/31/2002#
If you're having stability issues (i.e., recurrent corruption), that's a problem that needs to be addressed -- it's usually due to human error, hardware problems or software issues (like AV software interfering with internal Jet write operations).
But the key determinant is how fast the MDB is growing. If you extrapolate out the historical growth rate and approach 2GBs within 5 years, I'd say you need to upsize soon. If it's more like 10 years, you should probably do it anyway. If it's 20 years, then, not so much.