Re: [sqlite] (no subject)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/07/12 17:54, Jay A. Kreibich wrote: > Except that adds about 10x the workload for the moderators. I'd rather > have the SQLite team working on code, even if it means suffering the > occasional spam message. Who says the SQLite team have to be

Re: [sqlite] (no subject)

On Wed, Jul 18, 2012 at 02:10:52PM -0700, Roger Binns scratched on the wall: > On 18/07/12 13:00, Richard Hipp wrote: > > We have taken to requiring moderator approval before accepting new > > members onto this mailing list. > A better approach as used elsewhere (eg Google & Yahoo groups) is that

Re: [sqlite] (no subject)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18/07/12 13:00, Richard Hipp wrote: > We have taken to requiring moderator approval before accepting new > members onto this mailing list. A better approach as used elsewhere (eg Google & Yahoo groups) is that the first ~10 messages from someone

Re: [sqlite] Performance probleme between 3.7.3 and 3.7.13

We found the problem but we don't have a good explanation for it. All database files were read-only (in development they are for our SCM). Opening these files with 3.7.3 work fine. The same file open with 3.7.13 take more than 1 second to connect per file. If we remove the read-only attribute

Re: [sqlite] (no subject)

For the removal of doubt: We have taken to requiring moderator approval before accepting new members onto this mailing list. And even so spam like that shown below sometime leaks through. There is an arms race on, with spammers getting ever more sophisticated in their attacks. Sorry for the

Re: [sqlite] Syatem.Data.SQLite Exception/Error handling viaTry...Catch

I have some vague memory that exception handling is screwy inside constructors, and it's better to create a naked object and then fill it in in an Init() method. But I have no idea where I read that, if it's correct, or even which language it applies to. Good luck! RobR

Re: [sqlite] Performance probleme between 3.7.3 and 3.7.13

We have a trace directly in the code to do this measurement. The problem is establishing the connection not the query itself. It is when we call sqlite3_open16() after a simple debugging session with 3.7.13 it take the 1 sec and with 3.7.3 it is no wait at all! Any idea? Stéphane Léger, ing.

Re: [sqlite] Performance probleme between 3.7.3 and 3.7.13

First we changed the sqlite3.c and sqlite3.h and we had the problem. So we change also update the odbc driver to the latest version same result. We didnt't change the wrapper because we are not sure what should be updated! Thanks. Stéphane Léger, ing. Technical Specialist HMI Group Marine

Re: [sqlite] Performance probleme between 3.7.3 and 3.7.13

On Wed, Jul 18, 2012 at 1:40 PM, wrote: > Hi, > > > > We are updating the version of sqlite from 3.7.3 to 3.7.13 in our > software. But we are having a performance problem and I suspect a new > configuration but I don't know which one. I read on the site but didn't >

Re: [sqlite] Performance probleme between 3.7.3 and 3.7.13

On 18 Jul 2012, at 6:40pm, stephane.le...@l-3com.com wrote: > We are using : > > C++ (CppSQLite3 wrapper), ADO, Sqlite ODBC driver > > Window 7 64 bits but the application is 32 bits. Which of those did you change in your upgrade ? Did you replace just your copies of sqlite3.c and sqlite3.h

[sqlite] Performance probleme between 3.7.3 and 3.7.13

Hi, We are updating the version of sqlite from 3.7.3 to 3.7.13 in our software. But we are having a performance problem and I suspect a new configuration but I don't know which one. I read on the site but didn't find anything obvious. We use sqlite to store our graphical page objects data.

Re: [sqlite] Syatem.Data.SQLite Exception/Error handling viaTry...Catch

Following is an example of a code block which generates the behavior I described. It is embedded in an application which employs .NET 4 trace features and implements log file and console trace listeners. The Try...Catch block is located in the constructor of a class which inherits

Re: [sqlite] Why is SQLiteConnection.DataSource set as the database file without its extension?

>>Ludovic VP wrote: >> > >Is there a reason why SQLiteConnection.DataSource is set to the > >database >>file without the extension? >> >I'm not sure; however, it cannot be changed at this point without breaking >backward compatibility. An similar method could be developed to allow the extension