Re: [sqlite] still struggling with "Database schema has changed" errors
>Could you post it here? I bet I am not the only other one curious about it. Here you go. I sent the same to Dr. Hipp, but I didn't hear anything back. It would be nice to add this option to SQLITE since it is just an additional TCL command switch. If you want to see the difference, use a program like Examdiff and compare it to the same file in the source code. It will show the differences. I used 3.08 as the source, but I would bet the file is the same in the current version.. Randall Fox
Re: [sqlite] still struggling with "Database schema has changed" errors
Randall Fox wrote: Do mind sharing or explaining your changes? No.. But I should have gave more information. My changes were for the TCL SQLITE code If you are using TCL, let me know I can send you the code, which is short and just adds another command line switch for the TCL sqlite3 instruction. Randall, Could you post it here? I bet I am not the only other one curious about it. TIA, Gerry
Re: [sqlite] still struggling with "Database schema has changed" errors
>Do mind sharing or explaining your changes? No.. But I should have gave more information. My changes were for the TCL SQLITE code, and just affected the way TCL accesses the library. I was also getting the schema errors when I was using a single threaded app. I was opening two instances but only one was in a write operation (or read for that matter ) at any given time. What you should do is check the operation specifically for this error and when you encounter it, try to re-execute the command repeatedly until it goes through. I found when I did get the error, retrying the same operation was successful -- and that is the same advice I saw earlier from the author of SQLITE. Personally, I would probably put a fail safe in the code to prevent an infinite loop. In fixing my problem, I did not use that method. Instead I passed in the pointer for the SQLITE DB I already had open to the TCL interpreter, and had TCL use the already opened DB pointer instead of opening another instance. This seems to take care of the problem, but is a poor choice on a multi-threaded app. If you are using TCL, let me know I can send you the code, which is short and just adds another command line switch for the TCL sqlite3 instruction. Randall Fox
Re: [sqlite] still struggling with "Database schema has changed" errors
Wow that's a lot different than what I
read in some of the messages I read in
the archive. I read that we're not
suppose to see SQLITE_SCHEMA errors
in SQLite3 unless something very wrong
happened.
Thanks,
Kervin
Dan Kennedy wrote:
There's a little bit written about SQLITE_SCHEMA errors here:
http://www.sqlite.org/faq.html#q17
--- "Kervin L. Pierre" <[EMAIL PROTECTED]> wrote:
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(_sqlite_cs);
databaseHandle = (sqlite3 *)TlsGetValue(otlkcon_tlsIndex);
if( databaseHandle == NULL )
{
// Thread does not have a db handle yet
sqlRes = sqlite3_open(databaseFilename, );
if ( sqlRes != SQLITE_OK )
{
// error code and exit...
}
sqlRes = TlsSetValue( otlkcon_tlsIndex, databaseHandle );
}
LeaveCriticalSection(_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
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Re: [sqlite] compiled features at runtime? - Re: [sqlite] still struggling with "Database schema has changed" errors
Jeff Thompson wrote: The way THREADSAFE works currently, is that it must be defined, but also must have a value assigned to it. The compiler switch /D THREADSAFE won't cause sqlite to have thread safe code included, whiel /D THREADSAFE=1 will. Ensure you're using the latter format, or That was at least part of my problem, thanks a lot for that tip. I was using '/D THREADSAFE' to turn on multi-thread support. - Kervin
Re: [sqlite] still struggling with "Database schema has changed" errors
There's a little bit written about SQLITE_SCHEMA errors here:
http://www.sqlite.org/faq.html#q17
--- "Kervin L. Pierre" <[EMAIL PROTECTED]> wrote:
> 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(_sqlite_cs);
> databaseHandle = (sqlite3 *)TlsGetValue(otlkcon_tlsIndex);
> if( databaseHandle == NULL )
> {
> // Thread does not have a db handle yet
> sqlRes = sqlite3_open(databaseFilename, );
> if ( sqlRes != SQLITE_OK )
> {
> // error code and exit...
> }
> sqlRes = TlsSetValue( otlkcon_tlsIndex, databaseHandle );
> }
> LeaveCriticalSection(_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
> >
> >
> >
> >
>
>
__
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail
Re: [sqlite] compiled features at runtime? - Re: [sqlite] still struggling with "Database schema has changed" errors
On Fri, 04 Feb 2005 16:54:31 -0500, Kervin L. Pierre
<[EMAIL PROTECTED]> wrote:
> Thanks for your response Chris.
>
> Is there a way to find out what components are
> compiled in at runtime?
>
I don't believe the way the THREADSAFE define is handled today would
allow you to check anything at run-time. I sent the following patch to
the mailing list just yesterday. I got a goofy bounce message, but I
thought the message had been sent to the list, but nobody's commented,
so maybe it never made it... :)
This patch will enable sqlite thread safe processing on windows with
the MSVC compiler, if the symbol _MT is defined. IMHO, this is a
better way to handle this, since it's automatic.
--- os_win.c17 Nov 2004 00:21:38 - 1.1
+++ os_win.c4 Feb 2005 04:10:02 - 1.2
@@ -21,6 +21,16 @@
/*
** Macros used to determine whether or not to use threads.
*/
+#if defined(_MSC_VER)
+# if defined(_MT)
+# define SQLITE_W32_THREADS 1
+# pragma message("sqlite3 thread-safe support enabled.")
+# else
+# undef SQLITE_W32_THREADS
+# pragma message("sqlite3 thread-safe support disabled.")
+# endif
+#endif
+
#if defined(THREADSAFE) && THREADSAFE
# define SQLITE_W32_THREADS 1
#endif
> I built sqlite myself and I did turn on that
> macro, but I want to double check everything
> at runtime. Maybe throw an error if
> multi-threading support is not available in
> the DLL.
>
The way THREADSAFE works currently, is that it must be defined, but
also must have a value assigned to it. The compiler switch /D
THREADSAFE won't cause sqlite to have thread safe code included, whiel
/D THREADSAFE=1 will. Ensure you're using the latter format, or
alternatively, us the patch I posted to have this detected
automatically when you're doing a multi-threaded build in MSVC vs.
single-threaded.
> Is there a way to detect multi-threading
> support at runtime?
>
You could do something like:
#if defined(THREADSAFE) && THREADSAFE
int g_isThreadSafe = 1;
#else
int g_isThreadSafe = 0;
#endif
and then check g_isThreadSafe in your code at run-time.
Hope that helps.
--
Jeff Thompson
[EMAIL PROTECTED]
Re: [sqlite] still struggling with "Database schema has changed" errors
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(_sqlite_cs);
databaseHandle = (sqlite3 *)TlsGetValue(otlkcon_tlsIndex);
if( databaseHandle == NULL )
{
// Thread does not have a db handle yet
sqlRes = sqlite3_open(databaseFilename, );
if ( sqlRes != SQLITE_OK )
{
// error code and exit...
}
sqlRes = TlsSetValue( otlkcon_tlsIndex, databaseHandle );
}
LeaveCriticalSection(_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
Re: [sqlite] still struggling with "Database schema has changed" errors
> 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? The docs for SQLite mention that you need to specifically compile the libs (DLL) with the THREADSAFE preprocessor macro set to 1 for you to be able to use SQLite in threads Not sure what the DLL's on the web site are compiled with, perhaps that's the issue?
Re: [sqlite] still struggling with "Database schema has changed" errors
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
[sqlite] still struggling with "Database schema has changed" errors
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? Thanks, Kervin
