Re: [sqlite] Shared Lock Transactions

POSIX defines read and write locks. A write lock is exclusive and a read lock inhibits a write lock from occurring. Any number of processes/threads can have a read lock but as long as one read lock is in place a write lock cannot be established. When a write lock is set no read or write

[sqlite] Re: Shared Lock Transactions

* Jay Sprenkle <[EMAIL PROTECTED]> [2007-01-22 01:40]: > This makes little sense. There are no 'shared' locks. I’m not sure where you got this idea, but shared locks are an OS-level concept in Unix. You cannot acquire a shared lock on a file as long as there are exclusive locks on it, and you

[sqlite] One DB fed from many DBs

Greetings. So, what is the best of way of doing the following scenario? We have a program manager system that has many users and each user have a local DB. There is also a central database that gets fed out of each of these local DBs. The program keeps an unique ID based on userID and a

Re: [sqlite] Shared Lock Transactions

Jay Sprenkle wrote Sorry, Accidently hit send before I was finished. This documentation needs to be updated so it makes sense. Making up this conceptual 'shared lock' thing instead of explaining how the locking mechanism really works is not helpful. A 'shared lock' in reality is just opening

Re: [sqlite] Shared Lock Transactions

On 1/21/07, Andrew Teirney <[EMAIL PROTECTED]> wrote: > > > What is a 'shared' lock? You can't share a lock, only one process can > > own it > > at a time. > > > > As per this document > > http://www.sqlite.org/lockingv3.html > > SHARED The database may be read but not written. Any number of >

Re: [sqlite] Shared Lock Transactions

On 1/21/07, Andrew Teirney <[EMAIL PROTECTED]> wrote: > What is a 'shared' lock? You can't share a lock, only one process can > own it > at a time. > As per this document http://www.sqlite.org/lockingv3.html SHARED The database may be read but not written. Any number of processes can hold

Re: [sqlite] Re: Shared Lock Transactions

Igor Tandetnik wrote: What happens if you run a dummy SELECT statement, such as "select 1;", right after a BEGIN? Would that acquire SHARED lock? Igor Tandetnik Unfortunately it doesn't appear like it does. I guess i could perform a dummy select that need the db in the same exec as the

[sqlite] Re: Shared Lock Transactions

Andrew Teirney <[EMAIL PROTECTED]> wrote: I was just wondering whether there might be any particular reason why there doesn't appear to be support for creating transactions that acquire a shared lock on execution of the BEGIN statement? The reason why i ask this is that i try and perform all my

Re: [sqlite] Shared Lock Transactions

Jay Sprenkle wrote: On 1/21/07, Andrew Teirney <[EMAIL PROTECTED]> wrote: I appologise in advance if this is not the correct place to post this query ... I was just wondering whether there might be any particular reason why there doesn't appear to be support for creating transactions that

Re: [sqlite] does select reliably return insert order?

--- [EMAIL PROTECTED] wrote: > "Robert Simpson" <[EMAIL PROTECTED]> wrote: > > > > By leaving it undocumented and not committing to today's implementation, DRH > > leaves himself open to change or optimize it later without breaking backward > > compatibility. > > > > Exactly. > >

Re: [sqlite] Fix for sqlite3.h in version 3.3.10

> >> Having SQLITE_TRANSIENT point to a real function is perhaps a > >> good idea. The problem is such a change would break backwards > >> compatibility of the API. Somebody who compiled against an > >> older SQLite and who drops in a newer DLL with this change will > >> find that their code no

Re: [sqlite] does select reliably return insert order?

"Robert Simpson" <[EMAIL PROTECTED]> wrote: > > By leaving it undocumented and not committing to today's implementation, DRH > leaves himself open to change or optimize it later without breaking backward > compatibility. > Exactly. Furthermore, if you put on an ORDER BY clause that would

Re: [sqlite] Shared Lock Transactions

On 1/21/07, Andrew Teirney <[EMAIL PROTECTED]> wrote: I appologise in advance if this is not the correct place to post this query ... I was just wondering whether there might be any particular reason why there doesn't appear to be support for creating transactions that acquire a shared lock on

Re: [sqlite] Re: does select reliably return insert order?

On 1/21/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > If you use LIMIT/OFFSET without an > explicit ORDER BY, you are relying on an implementation detail. Yes, but SQLite is an implementation. If it returns rows allways in the same order I don't see why it shouldn't be acknowledged - one

RE: [sqlite] Re: does select reliably return insert order?

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Sunday, January 21, 2007 2:40 AM > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Re: does select reliably return insert order? > > > > If you use LIMIT/OFFSET without an > > explicit ORDER BY, you are

[sqlite] Shared Lock Transactions

I appologise in advance if this is not the correct place to post this query ... I was just wondering whether there might be any particular reason why there doesn't appear to be support for creating transactions that acquire a shared lock on execution of the BEGIN statement? The reason why i

Re: [sqlite] UPDATE with join on ROWID

On Sunday, January 21, 2007, 1:17:09 PM, RB Smissaert wrote: > Need to do an UPDATE on one table, based on values in another table where > this other table is joined to the first table on rowid of table 1 = column > value of table 2, so: > UPDATE > table1 > SET col2 = >

[sqlite] Re: UPDATE with join on ROWID

Forget about this one, I can of course just to do: UPDATE table1 SET col2 = (SELECT t2.col2 FROM table2 t2 WHERE table1.ROWID = t2.col1) Must have been looking too much at complex things, so overlooking the simple ones. RBS

[sqlite] UPDATE with join on ROWID

Need to do an UPDATE on one table, based on values in another table where this other table is joined to the first table on rowid of table 1 = column value of table 2, so: UPDATE table1 SET col2 = (SELECT t2.col2 FROM table2 t2 WHERE ROWID = t2.col1)

Re[2]: [sqlite] Fix for sqlite3.h in version 3.3.10

On Sunday, January 21, 2007, 11:03:32 AM, Florian Weimer wrote: >> Having SQLITE_TRANSIENT point to a real function is perhaps a >> good idea. The problem is such a change would break backwards >> compatibility of the API. Somebody who compiled against an >> older

Re: [sqlite] Fix for sqlite3.h in version 3.3.10

> Having SQLITE_TRANSIENT point to a real function is perhaps a > good idea. The problem is such a change would break backwards > compatibility of the API. Somebody who compiled against an > older SQLite and who drops in a newer DLL with this change will > find that their code no longer works.