One overall comment before I address some of your points below. MS SQL Server and SQLite are intended for vastly different audiences, audiences whose requirements different to a significant degree. While there may be some edge cases where both of them are appropriate, I think those are likely to be rare.
You need to figure out what capabilities you need, then figure out what to use to meet that need. Instead, you seem to be approaching this from the "I want to use SQLite, so I need reasons to do so" standpoint, i.e. looking for facts to justify your position, rather than letting the facts show you what your position ought to be. That is exactly the wrong way to make this decision, and you are doing yourself, your developers and your users a disservice to try. > 1. SQLite has "Zero Installation". This means that all that is > needed to run SQLite is to copy the database on the machine along with > the program which accesses it. There is no need to adjust the registry > for SQLite. While true, it's not particularly relevant. SQL Server is not intended to be installed on the client machine, nor would it be in the normal course of events. The client application would connect to a SQL Server instance running elsewhere. And I've written many apps that don't need to modify the registry on the client machine to access SQL Server. > 2. An SQLite database is exactly one file. SQL Server 7 has many > files for each table in the database. Not quite true. While one *can* define* many different physical files for a single database, it's not generally considered good practice unless one has special needs (and the hardware to go with it). The most common configuration appears to be one file for the database, and one file for the transaction log. A situation not that dissimilar to SQLite. It's not relevant anyway, since the client need know nothing about the physical configuration of the server, where it keeps it's files and how many of them there are. It only needs to know how to talk to the server itself. > 3. SQLite is much faster than SQL Server 7. In what regard? There are *lots* of things going on in a relational database, making this general statement about all of them is...misleading. > 5. SQLite has an active community with good people which help each > other solve rather complex programming problems. So does Microsoft. I've found lots of help on the news groups related to SQL Server. > 6. SQL Server 7 is obsolete and the database is not upward > compatible. Uh, no. Completely wrong. We still have a number of SQL Server 7 dbs, as there's no reason to upgrade them, and our client apps access those and the SQL Server 2000 servers with no problem whatsoever. > 8. SQL Server 7 requires powerful hardware to run. SQLite runs on > cheaper hardware. Hmmmm. I'm running 2000 at home on a Pentium III 450 with 64 meg of ram. Works pretty well, too. 'Course, like I said before, this choice really depends on what you need it for. > 10. SQLite runs on almost ever operating systems. SQL Server runs > on MS Windows exclusively. True as far as it goes, but again, not particularly relevant. Only the server needs to run on Windows. However there are SQL Server drivers for other languages, even cross-platform ones such as Java, that enable clients to operation on a wide variety of platforms. > 11. By using SQLite you eliminate a possible source of virus > infection. SQL server has been targeted in at least one major virus > outbreak. Completely and totally false. Applications that use SQLite can be corrupted and infected by viruses just like any other executable file on the file system.
