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
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. However, I ma
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_close_v2
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 behavior of sqlite3_close(
-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
. 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
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
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*
Bronislav wrote:
I usualy download every new version of SQLite, ...there is no change in description
since 2003/10. Should that
mean that there was no change?
There isn't a change in the public API at every update. If there is a
change in the version number, then there are obviously changes in
Hi,
I usualy download every new version of SQLite, I'm writing my own Delphi
interface but there is no change in description since 2003/10. Should that
mean that there was no change?
Brona
-
To unsubscribe, e-mail: [EMAIL
11 matches
Mail list logo
