-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> A far better solution ... would be to bump
> the VFS version number to 3
That is the only solution that will not break any existing code from anyone.
ie you have to use VFS 3 to opt in to getting SYNC_OMITTED (probably best
delivered to xSy
On Wed, Jan 26, 2011 at 12:20 AM, Roger Binns wrote:
> -
> A far better solution ... would be to bump
> the VFS version number to 3
Suppose we rig the default VFSes so that they return SQLITE_OK for
SQLITE_FCNTL_SYNC_OMITTED, instead of SQLITE_ERROR, so that your
intermediate layer doesn't thro
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/25/2011 08:56 AM, Richard Hipp wrote:
>> Thanks for the helpful feedback. Please let us know if you find this
>> solution inadequate or if you encounter other problems.
A far better solution to this kind of thing is to do them the other way
rou
On Tue, Jan 25, 2011 at 11:31 AM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> The issues I have with this file control are:
>
> - - It is documented as "internal" but my code sees it hence it is now part
> of
> the external interface of SQLite
>
You are right. This has been fixed.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/24/2011 09:27 PM, Dan Kennedy wrote:
> Does the aspw xFileControl method modify the value of the output
> parameter in this case?
No.
> The idea was that existing VFS implementations would return SQLITE_ERROR
> since they do not recognize SQLIT
On 01/25/2011 12:20 PM, Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 01/24/2011 06:05 PM, Roger Binns wrote:
>> I'm finding custom VFS code is no longer working at all.
>
> The cause is a new xFileControl operation SQLITE_FCNTL_SYNC which appears to
> needlessly dupli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/24/2011 06:05 PM, Roger Binns wrote:
> I'm finding custom VFS code is no longer working at all.
The cause is a new xFileControl operation SQLITE_FCNTL_SYNC which appears to
needlessly duplicate the existing xSync method.
Additionally unlike ot
On 01/25/2011 04:10 AM, Black, Michael (IS) wrote:
> Is this if statement meant to be constant? Or should it be comparing the
> requested encoding instead of SQLITE_UTF16NATIVE?
>
> SQLITE_PRIVATE int sqlite3Utf16ByteLen(const void *zIn, int nChar){
>int c;
>unsigned char const *z = zIn;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/24/2011 10:12 AM, Richard Hipp wrote:
> Unless serious problems
I'm finding custom VFS code is no longer working at all. Mine "inherits"
from an existing one overriding or calling the original methods as
appropriate. My code for this is uncha
nformation Systems
> Advanced Analytics Directorate
>
>
>
>
> From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on
> behalf of Richard Hipp [d...@sqlite.org]
> Sent: Monday, January 24, 2011 12:12 PM
> To: sqlite-...@sq
Around line 59981
sqlite3StrAccumAppend(&out, zStart, zRawSql-zStart);
The zRawSql-zStart is a 64-bit value (on a 64-bit machine) but gets
down-converted to int.
Seems a little more error checking is appropriate to ensure this doesn't exceed
an int.
Would be an awfully long SQL string but poten
SQLITE_PRIVATE int sqlite3Utf16ByteLen(const void *zIn, int nChar){
int c;
should be
unsigned int c;
Otherwise I don't think the macros work right (they become constant expression
warnings).
Michael D. Black
Senior Scientist
NG Information Systems
Advanced Analytics Directorate
_
Is this if statement meant to be constant? Or should it be comparing the
requested encoding instead of SQLITE_UTF16NATIVE?
SQLITE_PRIVATE int sqlite3Utf16ByteLen(const void *zIn, int nChar){
int c;
unsigned char const *z = zIn;
int n = 0;
if( SQLITE_UTF16NATIVE==SQLITE_UTF16BE ){
ite Database
Subject: EXTERNAL:[sqlite] SQLite version 3.7.5 - code freeze
The current plan is to release SQLite version 3.7.5 on Wednesday of next
week 2011-02-02. Please see draft release notes here:
http://www.sqlite.org/draft/releaselog/3_7_5.html
You can download a snapshot of the latest
ar to ...".
Marian Cascaval
From: Richard Hipp
To: sqlite-...@sqlite.org; General Discussion of SQLite Database
Sent: Mon, January 24, 2011 8:12:44 PM
Subject: [sqlite] SQLite version 3.7.5 - code freeze
The current plan is to release SQLite version 3.7.5 on Wednesday of next
week 20
The current plan is to release SQLite version 3.7.5 on Wednesday of next
week 2011-02-02. Please see draft release notes here:
http://www.sqlite.org/draft/releaselog/3_7_5.html
You can download a snapshot of the latest SQLite amalgamation from here:
http://www.sqlite.org/draft/downl
16 matches
Mail list logo
