Why should I use SQLite over a Jet database

Question

Someone asked me this the other day, and I couldn't think of a good answer. Platform portability is completely irrelevant to the project.

In fact, Jet has some features that SQLite does not, namely foreign keys.

So can anyone think why SQLite should be used instead of a Jet database?

Answer 1

Contrary to what other people are saying, Jet is not dead and far from it: ACE is the new version of Jet and it's pretty robust and backward compatible.

Both SQLite and Jet/ACE have their strengths and weaknesses and you need to get more information about the specific points that are important to you and your application.

• In either case you can redistribute the engine.
• Jet/ACE is a bit more integrated and supported out of the box in MS tools and Visual Studio.
• Jet/ACE has more granular locking, which may be important if your app allows multi-users or needs multi-threaded access to the database.
• Jet/ACE has more features in terms of what you would expect from a database (joins, unions and complex queries).
• Jet/ACE has a simple migration path to SQL Server, so if your database needs become big, you could move to SQL Server fairly easily.
• SQLite is cross-platform, so if your app needs to be ported to Linux/Mac under Mono then SQLite is a better choice.
• the SQLite engine is tighter so redistributing may be easier.
• datatypes are quite loose in SQLite.
• SQLite has more liberal redistribution rights (since you can basically do whatever you want with it).

People who say that Jet corrupts databases are stuck in 1995.

In the end, unless your application has some very specific requirements that are pushing the boundaries of either database engines, then it probably doesn't matter which one you chose.
Just use the one that easiest for you to include in your project.

Answer 2

SQLite is superior to Jet for the major reason that SQLite is ACID-compliant whereas Jet, unfortunately, isn't. If data integrity is an issue, SQLite offers a much more "robust" platform for your data storage requirements. See "SQLite Is Transactional" and "Atomic Commit In SQLite" for more details.

SQLite does indeed lack a few features (such as foreign keys), however, these are primarily due to SQLite being specifically developed as being an extremely small and lightweight database that is also serverless.

The serverless aspect of SQLite is also a major benefit over Jet in that nothing needs to be installed on the machine that will run your database. For example, I have used SQLite in an ASP.NET web application and all I needed was the SQLite DLL (in this case is was the excellent System.Data.SQLite drop-in replacement) in my application's "bin" folder, and my database in the application's "App_Data" folder. I could then upload these files to my webhost, and it all "just worked". This is without having to actually install or register anything on the target machine.

A small dowside of SQLite is due to the database being file-based. Database writes will lock the entire database file rather than a specific row or table, whereas Jet will offer you a more granular level of locking. Another small issue, based on the same file-based reasoning, is concurrency, however Jet itself does not offer a high level of concurrency either.