> > Although I can understand the sarcasm you're sending out, a > > client/server infrastructure would be an interesting task for > > SQLite to do, but to answer the OP, no, SQLite isn't inherently > > designed to be a client/server.
> ?And not really that difficult. Embed SQLite into some "server code" to > which a client connects, probably via TCPIP or some other IPC method.? The > client connects to the server, which uses the embedded SQLite to access > the appropriate SQLite data base file. I would guess that the server could > even be multi-threaded with each thread controlling a separate SQLite data > base > file. That is exactly what a client/server database is. It is an embeded database engine (DB/2, Microsoft SQL Server, Oracle, PostGres, etc, etc, etc) that only works against files located on the local filesystem, wrapped up (embeded) in some sort of RPC mechanism to marshal procedure calls and data from the client, and execute those calls on the database engine and return the result to the caller. If you embedded SQLite in a "Server" application, then you would have a Client/Server SQLite database. As the saying goes, inside every big program is a little program trying to get out ...
