I think you can hide those details, you can perfectly retrieve all rows (or bunch of rows) and then do not make any network access, but still simulate the sqlite API.
I would keep the connection open, it doesn't block other clients to connect as well, just the server has to be multi-process. the idea behind is to keep the existing code and make your application working with a database located on a server. If you want to go to a real database server, why not going directly to PostgreSQL? Best regards, Sylvain On Wed, Dec 22, 2010 at 11:52 PM, Doug <pa...@poweradmin.com> wrote: > This is where I think the problems will crop up. Can you imagine making a > network round trip for each row fetch, > and then for each column fetch of each row (sqlite3_column_type, > sqlite3_column_double, etc). > > To avoid that, you would need to fetch a lot (buffer) of data and bring it > back to the client. And if the response is > large, will you page, or keep the transaction open on the server thus > blocking all other clients? > > The devil is always in the details :) > > Doug > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Sylvain Pointeau > Sent: Wednesday, December 22, 2010 7:51 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLite server > > Why not doing it with DCOM or Corba or what ever even the sockets? > but hidden behind the same API of SQLite. The "real" sqlite lib will be on > the server. > is it called "remote procedure call"? > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
