I wrote a little server based on SQLite, and it works just fine. I
handled the "multiple processes" issue by simply having the software
make a list of requests, then handling those requests serially.
Essentially there are two parts to the software. One listens for
requests and lists them. It does nothing else, and it does the job with
as little overhead as possible, including minimal overhead. I took the
easy way out and the list is on a ramdisk, so I didn't have to deal with
interprocess communications.
The second part of the software takes requests off the bottom of the
list, (FIFO) does gobs of error checking, then processes the request.
Unless you expect to have massive numbers of users bombarding the
server, it should work fairly well.
Alex
Allan Miller wrote:
Hi Mark:
We briefly considered using JET (the Microsoft database engine for Access), but
went with SQLite in the end for a few reasons:
1. portability was important to us
2. open source with lots of applications (seems very well supported)
3. it seems to handle large databases very well
One of our deciding factors was that POPFile switched to SQLite and its author
was very pleased with it.
Also, if you ever have to look at the source code, it's a real pleasure to read,
compared to many open-source projects I've seen.
If you really need tight integration with Microsoft Office applications, you'll
probably
be happier with JET, but otherwise, I think you'll find SQLite will exceed your
expectations.
The only "weak point" of SQLite is its support for multiple processes accessing
the same database. That leaves something to be desired, but to be fair, that's
not
really what it was designed for. JET isn't exactly stellar in that department
either.
One thing to keep in mind is that if you write your own interface layer to the
database
and make it fairly generic, and try to stay away from SQL extensions, you can
minimize
the effort needed to switch to another database should that become necessary.
Also, we've never used it, but I know that there is an ODBC driver for SQLite,
so
that may satisfy your needs for using the Access front-end, integrating with
other
applications, etc.
Allan Miller
----- Original Message -----
From: "Allan, Mark" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, September 06, 2006 1:05 PM
Subject: [sqlite] SQLite vs MS Access
Hi,
After successfully using SQLite on an embedded device, we are now thinking of
using SQLite in a PC application.
This would be used in place of an MS Access database on a local/network disk. I
believe that SQLite should be quicker for both
transactions and queries than Access. The one draw back that comes to mind
maybe portability (i.e. accessing data outside of the
application), although the data would be portable across machines (PC, Mac,
Unix, etc) should we ever need it to be in the future.
Is there any webpage, or does anyone have any information comparing the
benefits of the two. I can only find comparisons between
MySQL and PostgreSQL. This information would aid us greatly in deciding whether
to use SQLite or stick with Access.
Any help/advice will be gratefully received.
Mark
DISCLAIMER:
This information and any attachments contained in this email message is
intended only for the use of the individual or entity to
which it is addressed and may contain information that is privileged,
confidential, and exempt from disclosure under applicable law.
If the reader of this message is not the intended recipient, or the employee or
agent responsible for delivering the message to the
intended recipient, you are hereby notified that any dissemination,
distribution, forwarding, or copying of this communication is
strictly prohibited. If you have received this communication in error, please
notify the sender immediately by return email, and
delete the original message immediately.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
