Re: [sqlite] Win32 coders: change os.c?

Can't do that. Naïve programmers will already know something needs to be done (convert UTF-16 to UTF-8) in order to use the sqlite functions in the first place. Their app won't compile if they try to feed in wide strings. Any follow-up thoughts? Rob -Original Message- From:

Re: [sqlite] Win32 coders: change os.c?

Not quite. IMHO, it's better that os.c catches this UNICODE macro, and then uses MultiByteToWideChar and WideCharToMultiByte inside. The other way is to use an assert(FALSE) to prevent compilation using UNICODE, then the naive programmers like me will know something needs to be taken care of. -A

Re: [sqlite] Can we load a db file to RAM ?

Open db file with the name ":memory:" (without the quotes). This gives you an in-mem database. -Arthur - Original Message - From: "Christian Hamar" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 17, 2003 1:41 PM Subject: [sqlite] Can we load a db file to RAM ? > Hi

Re: [sqlite] Performance tuning question

Hello, I managed to download new CVS versions (by hand ...) and compile them on Win32 platform (finally). Following are my test results: Time elapsedADO.NetSQLite 2.8.6SQLite CVS 0 0 0 0 30 7419 5

Re: [sqlite] Performance tuning question

Hello Andrew, I'm a little confused about the precompiled SQL. According to Wiki, there should be something like sqlite_bind() that I can use. However, I can't find sqlite_bind() in my sqlite source ... I'll try the sqlite_create_function(). Thanks. Regards, Arthur - Original Message --

[sqlite] Performance tuning question

Hello, I'm new to sqlite and I'm using it in my MFC program. I compiled the sqlite lib myself. I'm using in-memory DB. My program has two threads, say thread A and B. Thread A is the producer, which inserts rows inside a table named 'master'. Thread B is a consumer, which selects and updates