Samuel Neff <[EMAIL PROTECTED]>
wrote:
> If I launch two sqlite3.exe processes to the same database and do
> "begin
> exclusive" in one and "begin" in the second I do not get a
> busy/locked error
> in the second (not until you run some other sql like select or
> insert).
BEGIN statement doesn't
If I launch two sqlite3.exe processes to the same database and do "begin
exclusive" in one and "begin" in the second I do not get a busy/locked error
in the second (not until you run some other sql like select or insert).
What situation can cause "begin" to get a busy/locked error? (plain begin,
Yes the BEGIN Transaction may get a BUSY/LOCKED error.
If the BEGIN fails then do not commit, If you do commit you'll get an error
indicating that the commit failed due to no active transaction
Gregor Brandt <[EMAIL PROTECTED]> wrote: When doing transactional commits I do
int error =
Gregor Brandt <[EMAIL PROTECTED]>
wrote:
> When doing transactional commits I do
>
> int error = sqlite3_Exec( .., "BEGIN TRANSACTION;", ... ) // can
> this ever return an error?
No, as far as I know. It just sets a flag in an internal data structure
associated with database connection.
> int
When doing transactional commits I do
int error = sqlite3_Exec( .., "BEGIN TRANSACTION;", ... )
// can
this ever return an error?
int error = sqlite3_exect( ..., "some update command", ... )
if I get an error code, must I never do the "COMMIT;". what if I do?
Thanks
5 matches
Mail list logo
