Different kind of db locking behaviour on Unix(Linux) vs. Windows?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Different kind of db locking behaviour on Unix(Linux) vs. Windows?

Iulian Popescu
Hello,

 

I have the following scenario that fails on Linux and executes fine on
Windows XP. Suppose the following SQL statement is executed by calling
sqlite3_exec:

 

SELECT mySqlFunction()

 

Inside the body of the mySqlFuntion() the following statement is executed
through a call to sqlite3_exec:

 

CREATE TEMP TABLE MyTempTable AS SELECT 'foo'

 

Followed by the statement:

 

DROP TABLE MyTempTable

 

The last statement execution fails on Linux (Fedora Core 4) with the
following error "database table is locked" but not on Windows XP. However
the following statement runs fine on both systems:

 

DELETE FROM MyTempTable

 

Would somebody know why is that happening?

 

Thanks,

Iulian

 

Reply | Threaded
Open this post in threaded view
|

Re: Different kind of db locking behaviour on Unix(Linux) vs. Windows?

D. Richard Hipp
"Iulian Popescu" <[hidden email]> wrote:

>
> I have the following scenario that fails on Linux and executes fine on
> Windows XP. Suppose the following SQL statement is executed by calling
> sqlite3_exec:
>
> SELECT mySqlFunction()
>
> Inside the body of the mySqlFuntion() the following statement is executed
> through a call to sqlite3_exec:
>
> CREATE TEMP TABLE MyTempTable AS SELECT 'foo'
>
> Followed by the statement:
>
> DROP TABLE MyTempTable
>
> The last statement execution fails on Linux (Fedora Core 4) with the
> following error "database table is locked" but not on Windows XP.
>
> Would somebody know why is that happening?
>

I wrote the code and I do not know why it is doing what you
observe. So I'm guessing not many other people know either.

I do know that RedHat has fcntl() locking bugs that
SQLite has to go to considerable trouble to work around.
Perhaps the same bugs exit in Fedora and the work-around
code isn't working quite right.  Just a guess....

--
D. Richard Hipp   <[hidden email]>