I think I've found the problem.
The next step in debugging was to find the actual sqlite3 library calls
I was making, just to make sure the delay wasn't somewhere else in my
code. Here's the trace statements:
GetTrendData() started at Thu Aug 24 16; sqlite object is at 056B9570.
select tag_key,value,datetime(value_timestamp, 'localtime') from
trend_view where trend_key=1 and value_timestamp <=
julianday('2006-08-22 16C
SqlOpen(): First sqlite3_step() called at Thu Aug 24 16:30:52 2006
; sqlite object is at 056C20E0.
Interrupt requested at Thu Aug 24 16:30:54 2006
for object at 056B9570.
CSqlOpen(): Back from first sqlite3_step() call at Thu Aug 24 16:32:04
2006
; sqlite object is at 056C20E0.
GetTrendData() finished at Thu Aug 24 16
The object pointer reported in the second statement is not the same as
the one in the first statement. The second statement's pointer is the
one that was used in the call to sqlite3_prepare(). The
sqlite3_interrupt() pointer had better be the same as the one in
sqlite3_prepare(), and it wasn't.
Bottom line: I was trying to interrupt the wrong sqlite3 object.
Once I figure out how to get the correct sqlite3 object to use in the
interrupt call, I'll let you know how it works.
Rob Richardson
RAD-CON INC.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
