Andrew,
Nice modification.. Did you buy any chance post this into the sqlite ticketing system?
It would be nice if sqlite would let you acquire a shared lock via the BEGIN statement.
No i didn't actually post this to the ticketing system, to be honest i
am very new to all this open
I have multiple thread reading the database and a thread inserting in or
updating the database.
when i try to simulate this case by executing sqlite3 from shell by
beginning a transaction from a shell and retrieving data from other shell
eveything works fine.
But when it's the cas from my C
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
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
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 transa
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
Hi There,
Currently i am going through the process of getting a compilation of
sqlite 3.3.7 going via cross compilation to mingw hosted on a linux x86
box. In doing this i discovered that there is a problem with the
Makefile.in where the install target has a dependency on sqlite3 instead
7 matches
Mail list logo
