Hi,

Thanks for your response.  I'm at wit's end
with this thing.

I do open the database multiple times, but
exactly once per thread.  I then keep the
sqlite3* on thread local storage and only
use that pointer on the thread it was created
on.  This is how I interpreted the documentation.
Is that correct?

I wrote a function to get a sqlite3* pointer.
Any method that requires SQLite API calls
GetDatabaseHandle() first...

EnterCriticalSection(&otlkcon_sqlite_cs);
    databaseHandle = (sqlite3 *)TlsGetValue(otlkcon_tlsIndex);
    if( databaseHandle == NULL )
    {
        // Thread does not have a db handle yet
        sqlRes = sqlite3_open(databaseFilename, &databaseHandle);
        if (  sqlRes != SQLITE_OK )
        {
                // error code and exit...
        }
        sqlRes = TlsSetValue( otlkcon_tlsIndex, databaseHandle );
    }
LeaveCriticalSection(&otlkcon_sqlite_cs);

http://cvs.sourceforge.net/viewcvs.py/otlkcon/otlkcon0/mstore/O_IProp.cpp?view=markup

Tls* functions provide thread local storage.
By my reckoning, this should garantee a strict
sqlite3*<->thread relationship.

Do mind sharing or explaining your changes?

Thanks,
Kervin


Randall Fox wrote:
On Thu, 03 Feb 2005 14:15:52 -0500, you wrote:


Hello,

I am using SQLite 3.0.8 in a Win32 threaded
environment.

I keep getting random "Database schema has changed"
errors even though I am using thread local
storage to make sure sqlite3_open() gets called
on each thread and a there is a sqlite3* per thread.

Has anyone had any luck with resolving SQLITE_SCHEMA
errors in a threaded environment?


How are you accessing the database?  Do you open it multiple times and
write to it?

I had the same problem with the schema errors. I was opening the
database twice, and when I would create a table with one of the open
instances, the other would get the schema error the next time I
started a write operation.


I did end up fixing it by rewriting part of the SQLITE code.

Randall Fox







Reply via email to