[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-19 Thread Dan Kennedy
On 03/18/2015 02:39 AM, Bart Smissaert wrote: > OK, let me try to explain: > > Simple table with primary integer key, call the field ID > > strSQL = "Insert into table1 values(?)" > > lReturnValue = sqlite3_prepare16_v2(lDBHandle, >StrPtr(strSQL), >

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Simon Slavin
On 17 Mar 2015, at 8:12pm, Bart Smissaert wrote: > Will do some timings, but as you guess the slowdown may be negligible. You know, on rereading the documentation for _reset() and _finalize() I can see why you thought you'd be able to check only the results for those calls. Unfortunately I

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Bart Smissaert
OK, thanks, I see now. Will do some timings, but as you guess the slowdown may be negligible. RBS On Tue, Mar 17, 2015 at 8:08 PM, Simon Slavin wrote: > > On 17 Mar 2015, at 8:00pm, Bart Smissaert > wrote: > > > OK, but I can find out from sqlite3_errcode after the loop if there was > an > >

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Simon Slavin
On 17 Mar 2015, at 8:00pm, Bart Smissaert wrote: > OK, but I can find out from sqlite3_errcode after the loop if there was an > error, saving all the checks inside the loop. > Would there be any harm from that?

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Bart Smissaert
OK, but I can find out from sqlite3_errcode after the loop if there was an error, saving all the checks inside the loop. Would there be any harm from that? RBS On Tue, Mar 17, 2015 at 7:52 PM, Simon Slavin wrote: > > On 17 Mar 2015, at 7:39pm, Bart Smissaert > wrote: > > > The result is fine

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Simon Slavin
On 17 Mar 2015, at 7:39pm, Bart Smissaert wrote: > The result is fine and no duplicates are inserted, only thing wrong is the > result the one from last sqlite3_finalize. > Note that I don't check the return values in the loop, maybe I should, but > it saves some time. The result you get from

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Bart Smissaert
OK, let me try to explain: Simple table with primary integer key, call the field ID strSQL = "Insert into table1 values(?)" lReturnValue = sqlite3_prepare16_v2(lDBHandle, StrPtr(strSQL), Len(strSQL) * 2,

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Hick Gunter
. Probably you are ignoring SQLITE_ERROR from your sqlite3_step() call. -Urspr?ngliche Nachricht- Von: Bart Smissaert [mailto:bart.smissaert at gmail.com] Gesendet: Dienstag, 17. M?rz 2015 19:19 An: General Discussion of SQLite Database Betreff: [sqlite] result of sqlite3_finalize zero

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Bart Smissaert
Have a simple table with a primary integer key. Doing an insert (with no insert or ignore or insert or replace) with duplicate values for this primary integer key field produces zero on sqlite3_finalize, but 19 from sqlite3_errorcode. I thought that the result value of sqlite3_finalize also should

[sqlite] result of sqlite3_finalize zero, but sqlite3_errcode produces (rightly) SQLITE_CONSTRAINT

2015-03-17 Thread Richard Hipp
On 3/17/15, Bart Smissaert wrote: > Have a simple table with a primary integer key. > Doing an insert (with no insert or ignore or insert or replace) with > duplicate values > for this primary integer key field produces zero on sqlite3_finalize, but > 19 from sqlite3_errorcode. I wrote a test