Hi,
Thanks for the information. Just to confirm that implementation, I am
returning SQLITE_OK for the functions
sqlite3OsLock
sqlite3OsUnlock
and the function
sqlite3OsCheckReservedLock returns 0 assuming that the file has not
reserved locks.
Please advice if this is Ok.
With regards,
Alle 20:04, mercoledì 18 agosto 2004, Doug Currie ha scritto:
You must link with a math library that includes sqrt.
Perhaps adding -lm (assuming you have libm.a and it has sqrt) to the
end of the TCC or LTLINK lines in the Makefile will help.
Thanks, now it's ok.
--
Email.it, the
D. Richard Hipp [EMAIL PROTECTED] writes:
More sophisticated programs that want more control can still
have it, even with check-in [1879]. If thread A is trying
to COMMIT and thread B is trying to UPDATE, you will get
a busy handler callback from thread A and an SQLITE_BUSY
reply from
More sophisticated programs that want more control can still
have it, even with check-in [1879]. If thread A is trying
to COMMIT and thread B is trying to UPDATE, you will get
a busy handler callback from thread A and an SQLITE_BUSY
reply from thread B. But the SQLITE_BUSY return from
D. Richard Hipp wrote:
Ned Batchelder wrote:
Perhaps a pragma or database setting? At the very least, a compile-time
switch?
I have your request. In the meantime, the original code that does busy
callbacks for RESERVED locks is still in pager.c, just commented out using
#if 0. You can
Because thread A is a low-priority background task, and I don't mind if it
has to start all over again, while thread B is a high-priority UI thread,
and I don't want it to wait. The responsiveness of the system depends
directly on how quickly B can get its work done. Thread A will only affect
I am wondering if there is some way that a SQLite database file can be
encrypted or password protected, or something similar to this? I would
like to prevent any mischievous users from digging through the database
if they figure it out to be a sqlite file.
Thanks!
Bob
Bob Dankert wrote:
I am wondering if there is some way that a SQLite database file can be
encrypted or password protected, or something similar to this? I would
like to prevent any mischievous users from digging through the database
if they figure it out to be a sqlite file.
An proprietary
If I insert a date into a SQLite DB like so:
CREATE TABLE TestDate (foo);
INSERT INTO TestDate VALUES ('2004-08-19 11:57:41');
and then select the data out:
SELECT strftime(%s,foo) FROM TestDate;
Output: 1092916661
Which is off by 7 hours, which I'm assuming is because SQLite assumes
that the
