These archives are identical and contain both
Windows and Linux binaries as well as the source.
There is a quickstart guide at the bottom of
Docs/uSQLiteServer FAQ.html
uSQLite is a network wrapper for SQLite. It turns SQLite into an RDBMS
but puts the emphasis on the 'Lite'. In fact it works in a somewhat
unconventional mmanner in order to make both servers and clients as
light,
portable and simple as possible. Readers who are not familiar with
SQLite are advised to visit www.sqlite.org.
uSQLite uses the TechFell protocol
for communications between clients and servers. This protocol was
originally designed for allowing embedded systems to directly access a
database, but has proved efficient in more general applications and in
conjunction with a suitable server (such as uSQLite server) may also be
used for inter-process and inter systems communications.
In automation systems it may be used to provide both database and
communications in a single package, and in many cases can eliminate the
need for communications middleware.
In a more general scenario it has the advantage that custom client
software may be built into the applications (it is very easy to write
and customize drivers) such that applications may be deployed without
the need for a separate database / database driver layer to install
and/or configure, in essence a distributed embedded database.
Features
Server supports concurrent users on a single mono threaded
database connection, all queries are executed in strict sequential
order.
Server can be compiled onto anything that has libc and Berkleyish
sockets (including winsock2). No threading or filesystem locking is
required.
Server startup parameters put limits on server resource usage.
Client queries can be clamped.
Uses a simple but effective built-in access control system that
assigns access levels to both users and networks (or individual IP's).
Client access has a "Human" mode which allows telenetting into
the server (primarily for commissioning and trouble shooting).
Clients are very simple, users can easily roll their own bindings
into just about anything programmable with a TCP/IP stack.
Users may share (actually must share)
temporary tables and memory based tables (useful for IPC).
No dependency on external mechanisms.
Drawbacks
You may not use transactions (or more correctly, transactions
must BEGIN and END in the same query or group of queries sent as a
single batch)
Poor latency when another user is running a very big query
(although clients may be forced to limit their queries, which IMHO is
a good thing in any database scenario).
See the Docs directory in the archive for the FAQ and quickstart guide.