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