On Tue, May 13, 2008 at 7:51 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> for version 3.6.0 we are considering a behavior change in which a call
> to sqlite3_close() will silently and automatically call
> sqlite3_finalize() on all outstanding prepared statements.
>
> D. Richard Hipp
> [EMAIL P
On Tue, May 13, 2008 at 08:22:07PM -0400, D. Richard Hipp wrote:
> Perhaps a better approach would be to modify sqlite3_close() to return
> SQLITE_MISUSE if called with unfinalized prepared statements and also
> fail and assert() in that case. That way, applications would crash
> during deve
MAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Robert Simpson
Sent: Wednesday, May 14, 2008 7:58 AM
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Proposed SQLite C/C++ interface behavior change.
I wrote this behavior into the SQLite.NET provider as well. Howeve
ehalf Of Roger Binns
Sent: Tuesday, May 13, 2008 7:56 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Proposed SQLite C/C++ interface behavior change.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Virgilio Alexandre Fornazin wrote:
> A good and new safe could be a sqlite3_clo
nt: Tuesday, May 13, 2008 5:22 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Proposed SQLite C/C++ interface behavior change.
On May 13, 2008, at 8:02 PM, Scott Hess wrote:
> On Tue, May 13, 2008 at 4:51 PM, D. Richard Hipp
> wrote:
>> The currently documented behavi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Virgilio Alexandre Fornazin wrote:
> A good and new safe could be a sqlite3_close_v2() call prototyped like
>
> int sqlite3_close_v2(sqlite3 * db, int closePendingStatements);
Funnily enough that is exactly what I provide in my Python wrapper for
SQL
. Richard Hipp
Sent: terça-feira, 13 de maio de 2008 20:51
To: General Discussion of SQLite Database
Subject: [sqlite] Proposed SQLite C/C++ interface behavior change.
The currently documented behavior of sqlite3_close() is that when it
called on a database connection that has unfinalized
> Does anybody have any thoughts on this proposed behavior changes for
> the sqlite3_close() interface?
>
> D. Richard Hipp
> [EMAIL PROTECTED]
Fine with me.
- Richard Klein
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:808
--Bob
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of D. Richard Hipp
Sent: Tuesday, May 13, 2008 5:22 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Proposed SQLite C/C++ interface behavior change.
On May 13, 200
On May 13, 2008, at 8:02 PM, Scott Hess wrote:
> On Tue, May 13, 2008 at 4:51 PM, D. Richard Hipp <[EMAIL PROTECTED]>
> wrote:
>> The currently documented behavior of sqlite3_close() is that when it
>> called on a database connection that has unfinalized prepared
>> statements is to return SQLI
On Tue, May 13, 2008 at 4:51 PM, D. Richard Hipp <[EMAIL PROTECTED]> wrote:
> The currently documented behavior of sqlite3_close() is that when it
> called on a database connection that has unfinalized prepared
> statements is to return SQLITE_BUSY and fail to close the connection.
> The rational i
The currently documented behavior of sqlite3_close() is that when it
called on a database connection that has unfinalized prepared
statements is to return SQLITE_BUSY and fail to close the connection.
The rational is that we did not want a call to sqlite3_close() to
destroy sqlite3_stmt*
12 matches
Mail list logo
