Re: [sqlite] FileLocks - help requied
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, Sankara Narayanan B D. Richard Hipp [EMAIL PROTECTED] 2004-08-18 06:09 PM Please respond to [EMAIL PROTECTED] To [EMAIL PROTECTED] cc Subject Re: [sqlite] FileLocks - help requied [EMAIL PROTECTED] wrote: Hi, I am currently porting sqlite 3.0 into my device application. The device is running on an ARM7TDMI processor. The filesystem available on device is Nucleus file system. For this file system I am not sure whether I have the file locking mechanisms as provided in Sqlite 3.0. But the advantageous situation I have is only one thread in the application will be accessing SQLite all time (all the sqlite interfaces are protected using semaphores and there will be no two threads simultaenously accessing sqlite at any time). For this requirement how do I implement my OS functions sqlite3OsLock and sqlite3OsUnlock? Is it possible to work with no locking mechanism? I find that the lock utilisation (in pager.c) is not available with switches. Please advice me on how I could modify the sqlite code accordingly. If only one thread or process is accessing the database at a time, then no locking is required. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
Re: [sqlite] New SQL Function.
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 professional e-mail, gratis per te: http://www.email.it/f Sponsor: Digitalpix stampa le tue migliori foto digitali * su vera carta fotografica professionale. Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid32d-8
Re: [sqlite] Concerns about checkin 1879
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 thread B. But the SQLITE_BUSY return from thread B did not clear any locks. There is nothing that prevents the program from rolling back thread A then reissuing the UPDATE statement of thread B. It seems that there's a (possibly difficult, depending upon the application architecture) bit of record keeping required in the application to track whether the busy handler was called. Might I suggest that SQLITE_BUSY_NOWAIT (a new error code) be returned whenever a busy condition is detected that does not go through the busy handler; and SQLITE_BUSY be returned after the busy handler times out. In the above example, thread A doing its COMMIT would call the busy handler callback and then, when necessary, return SQLITE_BUSY, while thread B doing its UPDATE, would immediately return SQLITE_BUSY_NOWAIT. There may be a more appropriate name for the new error code... SQLITE_BUSY_LOCKED maybe? Does this have merit? Derrell
Re: [sqlite] Concerns about checkin 1879
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 thread B did not clear any locks. There is nothing that prevents the program from rolling back thread A then reissuing the UPDATE statement of thread B. OK, maybe I'm just not getting something here, but why on earth would I want to roll back a commit in order to allow an update? Shouldn't it be the other way around? If thread A has completed it's update, and is now in the process of committing that change, why does that *not* take precedence over a thread that is just now starting it's update?
Re: [sqlite] Concerns about checkin 1879
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 find it at line 2420 in the latest version of pager.c. You can easily change it back in your local copy. There is now a compile-time switch: SQLITE_BUSY_RESERVED_LOCK. A pragma is still under consideration. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
RE: [sqlite] Concerns about checkin 1879
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 the overall throughput of the system, and I know it will eventually get its chance, so I don't mind if it has to redo a bunch of work. --Ned. -Original Message- From: Brass Tilde [mailto:[EMAIL PROTECTED] Sent: Thursday, August 19, 2004 9:24 AM To: [EMAIL PROTECTED] Subject: Re: [sqlite] Concerns about checkin 1879 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 thread B did not clear any locks. There is nothing that prevents the program from rolling back thread A then reissuing the UPDATE statement of thread B. OK, maybe I'm just not getting something here, but why on earth would I want to roll back a commit in order to allow an update? Shouldn't it be the other way around? If thread A has completed it's update, and is now in the process of committing that change, why does that *not* take precedence over a thread that is just now starting it's update?
[sqlite] Encrypt or somehow protect database?
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
Re: [sqlite] Encrypt or somehow protect database?
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 encryption add-on is available for SQLite. This add-on encrypts each page of the database file separately using the RC4 algorithm. To an outside observer (someone without knowledge of the key) the database file looks like it contains white noise. The encrypted version of SQLite is available in source-code form for a one-time licensing fee. This enhancement is available for both SQLite version 2.8 and 3.0. Contact me directly for additional information. -- D. Richard Hipp -- [EMAIL PROTECTED] -- 704.948.4565
[sqlite] SQL DateTimes
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 date I entered in the DB was in UTC time (which it's not it's
compensated to my localtime zone). Is there any way to have SQLite be
aware that the date entered is not UTC? Can I append the timezone on the
end of the string?
Also when calculating dates using the 'localtime' modifier where does
SQLite get the information regarding the local timezone? Is it an
environment variable somewhere?
http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions
