Re: [sqlite] Client/Server Best Practices

2015-01-16 Thread Richard Hipp
On 1/16/15, James K. Lowden wrote: > On Sat, 10 Jan 2015 00:58:25 -0700 > "Keith Medcalf" wrote: > >> > there's no way to hook two SELECTs together to make them see one >> >database state. That's what JOIN is for. :-) >> >> Yes, it is a part of the

Re: [sqlite] Client/Server Best Practices

2015-01-16 Thread James K. Lowden
On Sat, 10 Jan 2015 00:58:25 -0700 "Keith Medcalf" wrote: > > there's no way to hook two SELECTs together to make them see one > >database state. That's what JOIN is for. :-) > > Yes, it is a part of the SQL Standard isolation levels in excess of > the default default of

Re: [sqlite] Client/Server Best Practices

2015-01-09 Thread Keith Medcalf
On Friday, 9 January, 2015 16:43, James K. Lowden said: >On Wed, 07 Jan 2015 21:47:24 -0700 "Keith Medcalf" wrote: >Along the same lines, since you mentioned it, >> in an SQLite database you can do: >> BEGIN >> SELECT ... >> SELECT ... >>

Re: [sqlite] Client/Server Best Practices

2015-01-09 Thread James K. Lowden
On Wed, 07 Jan 2015 21:47:24 -0700 "Keith Medcalf" wrote: > >As I said, your description (which I trust is accurate) is very > >helpful to someone who wants to understand how SQLite will act on > >the SQL provided to it. But it also protrays problematic choices > >that

Re: [sqlite] Client/Server Best Practices

2015-01-09 Thread Rick Kelly
Thanks for all the sage observations. As a server with a connection pool, I'm avoiding some of issues brought up. Every thread has their own connection handle and when done, it goes back into the pool so no sharing. I spent some hours reading everything I could find about this product and

Re: [sqlite] Client/Server Best Practices

2015-01-07 Thread Keith Medcalf
On Wednesday, 7 January, 2015 22:57, Kevin Benson said: >-- The OP wrote: >On Thu, Dec 25, 2014 at 7:32 AM, Rick Kelly wrote: >>*SNIP* >> The database file is located in the same folder as the server. The >server >is >> multi-threaded. I'm using

Re: [sqlite] Client/Server Best Practices

2015-01-07 Thread Kevin Benson
On Wed, Jan 7, 2015 at 11:47 PM, Keith Medcalf wrote: > On Wednesday, 7 January, 2015 20:01, James K. Lowden < > jklow...@schemamania.org> said: > >On Fri, 02 Jan 2015 21:41:02 -0700 > >"Keith Medcalf" wrote: > >> On Friday, 2 January, 2015 16:26, James

Re: [sqlite] Client/Server Best Practices

2015-01-07 Thread Keith Medcalf
On Wednesday, 7 January, 2015 20:01, James K. Lowden said: >On Fri, 02 Jan 2015 21:41:02 -0700 >"Keith Medcalf" wrote: >> On Friday, 2 January, 2015 16:26, James K. Lowden >> said: >> >> >On Thu, 25 Dec 2014 05:32:45

Re: [sqlite] Client/Server Best Practices

2015-01-07 Thread James K. Lowden
On Fri, 02 Jan 2015 21:41:02 -0700 "Keith Medcalf" wrote: > On Friday, 2 January, 2015 16:26, James K. Lowden > said: > > >On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly > > wrote: > > >> All SELECT type requests are wrapped

Re: [sqlite] Client/Server Best Practices

2015-01-03 Thread Simon Slavin
On 3 Jan 2015, at 4:41am, Keith Medcalf wrote: > I do not believe that there is a way to specify "COMMIT BUT MAINTAIN THE > SHARED LOCK", (that is, to commit the changes only and un-escalate the lock > back to a shared lock) which would be required in order for the loop

Re: [sqlite] Client/Server Best Practices

2015-01-02 Thread Keith Medcalf
On Friday, 2 January, 2015 16:26, James K. Lowden said: >On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly wrote: >> All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT >That shouldn't be necessary and afaik isn't necessary.

Re: [sqlite] Client/Server Best Practices

2015-01-02 Thread J Decker
On Fri, Jan 2, 2015 at 3:25 PM, James K. Lowden wrote: > On Thu, 25 Dec 2014 05:32:45 -0700 (MST) > Rick Kelly wrote: > > > All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT > > That shouldn't be necessary and afaik isn't necessary.

Re: [sqlite] Client/Server Best Practices

2015-01-02 Thread James K. Lowden
On Thu, 25 Dec 2014 05:32:45 -0700 (MST) Rick Kelly wrote: > All SELECT type requests are wrapped with BEGIN TRANSACTION/COMMIT That shouldn't be necessary and afaik isn't necessary. SELECT does not modify the database. To "commit a select" is to apply the nonchanges. A

Re: [sqlite] Client/Server Best Practices

2014-12-25 Thread Rick Kelly
Clients know nothing about the database, they just submit a request and get results. The server is the only process accessing and using SQLite. Rick Kelly -- View this message in context: http://sqlite.1065341.n5.nabble.com/Client-Server-Best-Practices-tp79728p79731.html Sent from the SQLite

Re: [sqlite] Client/Server Best Practices

2014-12-25 Thread Simon Slavin
On 25 Dec 2014, at 12:32pm, Rick Kelly wrote: > If a request encounters %SQLITE_BUSY or %SQLITE_LOCKED, I'm retrying up to 5 > times with a 100ms sleep in between. > > Will this approach minimize %SQLITE_BUSY and %SQLITE_LOCKED situations and > provide decent concurrency and

Re: [sqlite] Client/Server Best Practices

2014-12-25 Thread Richard Hipp
On Thu, Dec 25, 2014 at 7:32 AM, Rick Kelly wrote: > I'm using SQLite3 for the first time and am looking to see if those more > experienced can look at my deployment and offer suggestions. > > I have a client/server application running on MS Windows communicating over > TCP/IP

[sqlite] Client/Server Best Practices

2014-12-25 Thread Rick Kelly
I'm using SQLite3 for the first time and am looking to see if those more experienced can look at my deployment and offer suggestions. I have a client/server application running on MS Windows communicating over TCP/IP supporting a few dozen clients. Basically, clients send a request to the server