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.
But, think of how torrents work. Everyone is a server, everyone is a client. Everyone has a connection to every other database, but, it has its own working copy to query against. If Client A updates a table, the statement is sent out to every other "server" it has a connection to. Any differences in the data can be synced from one to another. Even with MySQL, the client has to pull the information it needs from the database to get its information and work with it locally in RAM (usually) then push the data back if there is anything to be done. Instead of the queries going to a MySQL server, you'd be talking to a server sitting right on your machine. Any queries from any other clients are done in another process/thread to the server database. (I'm actually kind of getting excited about this kind of coding, honestly.....) This isn't to say that this kind of infrastructure would be CRAZY to do, but it isn't impossible, and the hurdles to get it done can be overcome. So although a gas burning electric stove seems odd, getting the gas to boil water to push the turbine to generate electricity to run the burners does fit the particular scenario. And a cubical sphere would be so freak'n awesome. If you get enough, it'd redefine "office pool"..... :] On Thu, May 7, 2015 at 10:38 AM, John McKown <john.archie.mckown at gmail.com> wrote: > > > ?Which is why I didn't even bother to consider answering the original > question. One requirement was "an embedded client/server data base". Unless > I am really confused, this would be like asking for a gas burning electric > stove made of wood. Or a cubical sphere. But I'm getting(getting?) > sarcastic again. > >
