[sqlite] IS a SQLite db of small size as good as reliable cache?

GB wrote: > So where have you got this wisdom from? It's just plain Bullshit! > > Just as most cache managers do, Windows cache manager uses some sort of LRU > caching scheme. So all data once read from file is kept in memory until either > some memory pressure occurs or it is simply pushed out by

[sqlite] IS a SQLite db of small size as good as reliable cache?

On Wed, 3 Feb 2016 23:25:33 +0100 GB wrote: > So where have you got this wisdom from? It's just plain Bullshit! > > Just as most cache managers do, Windows cache manager uses some sort of > LRU caching scheme. So all data once read from file is kept in memory > until either some memory

[sqlite] IS a SQLite db of small size as good as reliable cache?

So where have you got this wisdom from? It's just plain Bullshit! Just as most cache managers do, Windows cache manager uses some sort of LRU caching scheme. So all data once read from file is kept in memory until either some memory pressure occurs or it is simply pushed out by newer data.

[sqlite] Segment fault when running a query

Hi, I've a reproduceable error in my code, running a simple SQL question gives me a segment fault. Running the program i gdb and doing backtrace gives me this: (gdb) backtrace #0 malloc_consolidate (av=av at entry=0x776be620 ) at malloc.c:4149 #1 0x77394ee8 in _int_malloc

[sqlite] Segment fault when running a query

Hi, I've a reproduceable error in my code, running a simple SQL question gives me a segment fault. Running the program i gdb and doing backtrace gives me this: (gdb) backtrace #0 malloc_consolidate (av=av at entry=0x776be620 ) at malloc.c:4149 #1 0x77394ee8 in _int_malloc

[sqlite] Bug: Successfully committed transaction rolled back after power failure

On Wed, 03 Feb 2016 06:30:13 -0700 "Keith Medcalf" wrote: > > Is this on windows? Any errors in the Eventlogs to the tune "Oooopsie -- > accidentally threw away your data instead of writing it to disk"? Windows > does this quite commonly under some circumstances. MicroSoft created the bug

[sqlite] Table entries disappearing for unknown reason.

Ok, the problem is solved. Thanks for the support. 2016-02-03 13:13 GMT-02:00 Vin?cius da Silva : > I think I have discovered the problem. SQLiteManager::init( const string& > dbFileName, const bool deleteDbFileFlag = true ) was deleting and > recreating the database file for each new

[sqlite] Table entries disappearing for unknown reason.

Vin?cius da Silva wrote: > Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does not > change the result I meant, try executing them so that they are guaranteed to conflict, like this: db1.init("same_file"); db2.init("same_file"); db1.beginTransactionExclusive();

[sqlite] a sqlite database error

Hello, my name is Frank. Two days ago, I operated sqlite database, and got an error, I don't known what the error means, so I hope if you see the email, please respond me. Thank you very much! iPhone

[sqlite] Bug: Successfully committed transaction rolled back after power failure

> Is this on windows? The original problem was on QNX 6.5 employing a QNX6 filesystem on mNAND flash. S.M. -- Dipl.-Phys. (Univ) Stefan Meinlschmidt, Senior Software Engineer Am Wolfsmantel 46, 91058 Tennenlohe, Germany Tel: +49-8458-3332-531 stefan.meinlschmidt at esolutions.de Fax:

[sqlite] Segment fault when running a query

Hi, I've a reproduceable error in my code, running a simple SQL question gives me a segment fault. Running the program i gdb and doing backtrace gives me this: (gdb) backtrace #0 malloc_consolidate (av=av at entry=0x776be620 ) at malloc.c:4149 #1 0x77394ee8 in _int_malloc

[sqlite] Table entries disappearing for unknown reason.

I think I have discovered the problem. SQLiteManager::init( const string& dbFileName, const bool deleteDbFileFlag = true ) was deleting and recreating the database file for each new connection. That was probably corrupting SQLite state and a SQLITE_IOERR_DELETE_NOENT was correctly being returned

[sqlite] Table entries disappearing for unknown reason.

With a single thread and two interleaved transactions, the tests hangs in what seems a deadlock. 2016-02-03 12:21 GMT-02:00 Clemens Ladisch : > Vin?cius da Silva wrote: > > Using BEGIN EXCLUSIVE TRANSACTION in place of BEGIN TRANSACTION does not > > change the result > > I meant, try executing

[sqlite] Customizing the location of the .sqlite_history

> Jes Slow wrote: > > > Many applications do this by allowing the user to set an environment > > variable to customize the location, altho personally I would prefer > > another way since environment variables are also global. > > Global? Environment variables are per-process, and changeable

[sqlite] Bug: Successfully committed transaction rolled back after power failure

Is this on windows? Any errors in the Eventlogs to the tune "Oooopsie -- accidentally threw away your data instead of writing it to disk"? Windows does this quite commonly under some circumstances. MicroSoft created the bug in NT 4 and has been unable to locate or fix it since -- though