date:20160713

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Simon Slavin


On 13 Jul 2016, at 5:22pm, Scott Robison  wrote:

> His program is not involved. Just the SQLite shell.

He's feeding the shell with a pre-prepared file.  Depending on how the OS 
command shell works, the result may depend on the text encoding used for the 
contents of that file.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Simon Slavin

On 13 Jul 2016, at 5:54pm, S.Ajina  wrote:

> SQLite version 3.13.0 2016-05-18 10:57:30

> Jap�n (2002)|4A6170C3B36E20283230303229
> 4A 61 70 C3 B3 6E 20283230303229

> SQLite version 3.8.6 2014-08-15 11:46:33

> Japón (2002)|4A6170C3B36E20283230303229
> 4A 61 70 C3 B3 6E 20283230303229

The fourth character in both cases is encoded as C3 B3 which is the correct 
UTF-8 encoding for LATIN SMALL LETTER O WITH ACUTE .

So the database is identical in both cases.  It's just that the 3.13.0 shell 
tool isn't displaying the contents correctly.

I don't know Windows enough to know what to do next.  Does it make any 
different if you issue the "codepage 65001" command before starting the  3.13.0 
shell to use the SELECT command ?

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Miroslav Rajcic


I will work on tracing all SQL calls and will get back to you.

Regards,

  Miroslav


On 13.7.2016. 13:05, Richard Hipp wrote:

On 7/13/16, Miroslav Rajcic  wrote:

Issue can be reproduced on Windows and Mac

Can you please send the steps needed to reproduce the problem?



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Simon Slavin

On 13 Jul 2016, at 4:09pm, S.Ajina  wrote:

> Doing the same with the current version of sqlite3.exe (version 3.13.0) 
> corrupts the database records when there are extended characters

I would guess that your program is handing extended characters to SQLite 
incorrectly.  All strings passed to SQLite are assumed to be Unicode strings.  
This includes not only strings used as parameters when binding to a SQL 
statement, but also the SQL statements themselves.

Given the way you phrased your question, I assume you've been using MBCS.

If you make up a string which depends on a Windows codepage, and do not 
explicitly convert this string to Unicode before handing it to SQLite, you will 
get bad results.  Maybe not immediately, but later, perhaps after indexing.

As a test, please execute this command against both versions of the database:

SELECT path,hex(path) FROM "test-directories" WHERE id=68

You (or we) should be able to tell what's happening from the results of that.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-13 Thread Scott Robison

On Jul 12, 2016 10:32 PM, "Cory Nelson"  wrote:
>
> While uncommon, it is not unheard of for apps to use include guards to
> check for a library's existence. While it is indeed not in compliance,
> in practice fixing this may affect existing SQLite users.

Good point, though personally I would weigh this in a different class of
backward compatibility changes. I don't think changing this would be bad.
But I also don't think a change is necessary.

Driving 51 in a zone posted 50 is also not in compliance (with a different
standard, of course). Yet we violate that standard all the time.

The reality is that I'm not aware of a single platform that will fail to
generate correct code for this (outside of treat all warnings as errors).

Yes, it is a standards violation in the strictest sense. Yet it's not a big
deal given the number of successful deployments.

If anyone can demonstrate an implementation that uses this identifier in a
way that is incompatible with SQLite, then it should be changed. Otherwise
it seems to me that disabling treat all warning as errors (or this one
warning in the impacted projects and files) is the least disruptive change
for all concerned.

>
> --
> Cory Nelson
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Simon Slavin

On 13 Jul 2016, at 6:26pm, Clemens Ladisch  wrote:

> To fix this, use the same mechanism for both output and input:
> 
>  sqlite3 old.db .dump > dump.sql
>  sqlite3 new.db < dump.sql
> 
> or
> 
>  (echo .output dump.sql && echo .dump) | sqlite3 old.db
>  sqlite3 -init dump.sql new.db

Showing my ignorance of Windows once again ... which of the above result in 
dump.sql having contents encoded in UTF-8 ?  I presume one does and one doesn't.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Clemens Ladisch

S.Ajina wrote:
> Can confirm that sqlite3.exe version 3.8.6 works ok restoring database from a 
> .dump dump.sql file using these commands
>
> echo .dump | sqlite3_v3.8.6   test.original.db   >  dump_v3.8.6.sql
> sqlite3_v3.8.6   -init   dump_v3.8.6.sqltest.restored.v3.8.6.db
>
> Doing the same with the current version of sqlite3.exe (version 3.13.0) 
> corrupts the database records when there are extended characters
>
> echo .dump | sqlite3_v3.13.0   test.original.db   >  dump_v3.13.0.sql
> sqlite3_v3.13.0   -init   dump_v3.13.0.sqltest.restored.v3.13.0.db
>
> Release Notes show changes in this area in version 3.10.0 which may have made 
> the change
> Translate between MBCS and UTF8 when running in cmd.exe on Windows

The old version of the sqlite3 shell assumes that screen and keyboard I/O
could be done with UTF-8.  This assumption was wrong.

The new version converts screen and keyboard I/O between UTF-8 and the
console's code page.  So the output redirection with > no longer uses
UTF-8.

To fix this, use the same mechanism for both output and input:

  sqlite3 old.db .dump > dump.sql
  sqlite3 new.db < dump.sql

or

  (echo .output dump.sql && echo .dump) | sqlite3 old.db
  sqlite3 -init dump.sql new.db


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Scott Robison

On Jul 13, 2016 9:55 AM, "Simon Slavin"  wrote:
>
>
> On 13 Jul 2016, at 4:09pm, S.Ajina  wrote:
>
> > Doing the same with the current version of sqlite3.exe (version 3.13.0)
corrupts the database records when there are extended characters
>
> I would guess that your program is handing extended characters to SQLite
incorrectly.  All strings passed to SQLite are assumed to be Unicode
strings.  This includes not only strings used as parameters when binding to
a SQL statement, but also the SQL statements themselves.

His program is not involved. Just the SQLite shell.

>
> Given the way you phrased your question, I assume you've been using MBCS.
>
> If you make up a string which depends on a Windows codepage, and do not
explicitly convert this string to Unicode before handing it to SQLite, you
will get bad results.  Maybe not immediately, but later, perhaps after
indexing.
>
> As a test, please execute this command against both versions of the
database:
>
> SELECT path,hex(path) FROM "test-directories" WHERE id=68
>
> You (or we) should be able to tell what's happening from the results of
that.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread S.Ajina

> As a test, please execute this command against both versions of the database:
> 
> SELECT path,hex(path) FROM "test-directories" WHERE id=68

Result of the query below

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.original.db
sqlite> .tables
spellfix_metadata_titles  test-directories
spellfix_tag_titles   test-media_parts
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Jap�n (2002)|4A6170C3B36E20283230303229
sqlite>

compare this output with doing the same when using sqlite3.exe version 3.8.6

SQLite version 3.8.6 2014-08-15 11:46:33
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.original.db
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Japón (2002)|4A6170C3B36E20283230303229
sqlite>

So there has been a change sometime between 3.8.6 and 3.13.0 

Regards

Simon

-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin
Sent: 13 July 2016 16:55
To: SQLite mailing list 
Subject: Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts 
records with extended characters

On 13 Jul 2016, at 4:09pm, S.Ajina  wrote:

> Doing the same with the current version of sqlite3.exe (version 3.13.0) 
> corrupts the database records when there are extended characters

I would guess that your program is handing extended characters to SQLite 
incorrectly.  All strings passed to SQLite are assumed to be Unicode strings.  
This includes not only strings used as parameters when binding to a SQL 
statement, but also the SQL statements themselves.

Given the way you phrased your question, I assume you've been using MBCS.

If you make up a string which depends on a Windows codepage, and do not 
explicitly convert this string to Unicode before handing it to SQLite, you will 
get bad results.  Maybe not immediately, but later, perhaps after indexing.

As a test, please execute this command against both versions of the database:

SELECT path,hex(path) FROM "test-directories" WHERE id=68

You (or we) should be able to tell what's happening from the results of that.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Scott Robison

On Jul 13, 2016 11:14 AM, "Simon Slavin"  wrote:
>
>
> On 13 Jul 2016, at 5:22pm, Scott Robison  wrote:
>
> > His program is not involved. Just the SQLite shell.
>
> He's feeding the shell with a pre-prepared file.  Depending on how the OS
command shell works, the result may depend on the text encoding used for
the contents of that file.

He generated a file from the shell (as I read it) and imported it. Round
trip failure.

If I misread, my apologies.

>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Richard Hipp

On 7/13/16, S.Ajina  wrote:
>> To fix this, use the same mechanism for both output and input:
>>
>>   sqlite3 old.db .dump > dump.sql
>>  sqlite3 new.db < dump.sql
>
> Yes this has worked. We use the method of dumping and recreating to overcome
> some database corruptions - often in the indexes. I presume doing it this
> way as you suggest would still lose any corruptions.

You shouldn't be getting corrupt databases.  I'd rather focus on
figure out why that is happening.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread S.Ajina

Thanks for the earlier advice.
will switch to using this method 
>  sqlite3 old.db .dump > dump.sql
>  sqlite3 new.db < dump.sql

I presume this can be adopted as the way to dump and recreate the database
on other platforms as well - OSX and Linux as well as windows and is
compatible with older versions of the operating systems and also sqlite3
shell utility

Regards

Simon

-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Clemens
Ladisch
Sent: 13 July 2016 18:26
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts
records with extended characters

S.Ajina wrote:
> Can confirm that sqlite3.exe version 3.8.6 works ok restoring database 
> from a .dump dump.sql file using these commands
>
> echo .dump | sqlite3_v3.8.6   test.original.db   >  dump_v3.8.6.sql
> sqlite3_v3.8.6   -init   dump_v3.8.6.sqltest.restored.v3.8.6.db
>
> Doing the same with the current version of sqlite3.exe (version 
> 3.13.0) corrupts the database records when there are extended 
> characters
>
> echo .dump | sqlite3_v3.13.0   test.original.db   >  dump_v3.13.0.sql
> sqlite3_v3.13.0   -init   dump_v3.13.0.sqltest.restored.v3.13.0.db
>
> Release Notes show changes in this area in version 3.10.0 which may 
> have made the change Translate between MBCS and UTF8 when running in 
> cmd.exe on Windows

The old version of the sqlite3 shell assumes that screen and keyboard I/O
could be done with UTF-8.  This assumption was wrong.

The new version converts screen and keyboard I/O between UTF-8 and the
console's code page.  So the output redirection with > no longer uses UTF-8.

To fix this, use the same mechanism for both output and input:

  sqlite3 old.db .dump > dump.sql
  sqlite3 new.db < dump.sql

or

  (echo .output dump.sql && echo .dump) | sqlite3 old.db
  sqlite3 -init dump.sql new.db


Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread S.Ajina

> To fix this, use the same mechanism for both output and input:
> 
>   sqlite3 old.db .dump > dump.sql
>  sqlite3 new.db < dump.sql

Yes this has worked. We use the method of dumping and recreating to overcome 
some database corruptions - often in the indexes. I presume doing it this way 
as you suggest would still lose any corruptions.

One thing that concerns me though is that using windows command line window 
with the sqlite3.exe v3.13.0 shell to interrogate a database and display 
records, is that the display is corrupted - the database is ok but display is 
not

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.restorednew.db
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Jap�n (2002)|4A6170C3B36E20283230303229
sqlite>

whereas version 3.8.6 does display the record ok. No change in select output 
with 3.13.0 even after `chcp 65001`

And also tried the following
>or
>
>  (echo .output dump.sql && echo .dump) | sqlite3 old.db
>  sqlite3 -init dump.sql new.db

But this sequence corrupted the database records

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.restorednew2.db
sqlite> .tables
spellfix_metadata_titles  test-directories
spellfix_tag_titles   test-media_parts
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Jap├│n (2002)|4A6170E2949CE294826E20283230303229
sqlite>

The sequence I used 
(echo .output newdump2.sql && echo .dump) | sqlite3_v3.13.0 test.original.db
sqlite3_v3.13.0 -init newdump2.sql test.restorednew2.db

Simon

-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Clemens 
Ladisch
Sent: 13 July 2016 18:26
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts 
records with extended characters

S.Ajina wrote:
> Can confirm that sqlite3.exe version 3.8.6 works ok restoring database 
> from a .dump dump.sql file using these commands
>
> echo .dump | sqlite3_v3.8.6   test.original.db   >  dump_v3.8.6.sql
> sqlite3_v3.8.6   -init   dump_v3.8.6.sqltest.restored.v3.8.6.db
>
> Doing the same with the current version of sqlite3.exe (version 
> 3.13.0) corrupts the database records when there are extended 
> characters
>
> echo .dump | sqlite3_v3.13.0   test.original.db   >  dump_v3.13.0.sql
> sqlite3_v3.13.0   -init   dump_v3.13.0.sqltest.restored.v3.13.0.db
>
> Release Notes show changes in this area in version 3.10.0 which may 
> have made the change Translate between MBCS and UTF8 when running in 
> cmd.exe on Windows

The old version of the sqlite3 shell assumes that screen and keyboard I/O could 
be done with UTF-8.  This assumption was wrong.

The new version converts screen and keyboard I/O between UTF-8 and the 
console's code page.  So the output redirection with > no longer uses UTF-8.

To fix this, use the same mechanism for both output and input:

  sqlite3 old.db .dump > dump.sql
  sqlite3 new.db < dump.sql

or

  (echo .output dump.sql && echo .dump) | sqlite3 old.db
  sqlite3 -init dump.sql new.db

Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Igor Korot

Simon,
As Mr Hipp pointed out - what problems you observed with SQLite?
It is possible that if you report it it will be fixed and you won't
need to do that restoration anymore.

Thank you.


On Wed, Jul 13, 2016 at 5:52 PM, S.Ajina  wrote:
>> What console font are you using, and which codepage?  The default OEM 
>> codepage is quite likely 437, and you may need to change it to 850.
>>
>> Codepage 437 is the original IBM ANSI OEM CodePage that contains line 
>> drawing characters.  Codepage 850 is the multilingual codepage that has 
>> multilingual characters in it.  I believe that the current shell is 
>> translating to MBCS (ie, the Windows ACP, usually 1252 for Western European 
>> languages) so you might want to try that codepage too.
>
> I must have switched to 65001 in that command line window - because the 
> SELECT query does display correctly with code page 437 and code page 850 
> (default)
>
> Results of tests
>
> Active code page: 437
>
> SQLite version 3.13.0 2016-05-18 10:57:30
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew.db
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Japón (2002)|4A6170C3B36E20283230303229
> sqlite>
>
> --
> Active code page: 850
>
> SQLite version 3.13.0 2016-05-18 10:57:30
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew.db
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Japón (2002)|4A6170C3B36E20283230303229
> sqlite>
>
> --
> Active code page: 1252
>
> SQLite version 3.13.0 2016-05-18 10:57:30
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew.db
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Jap¢n (2002)|4A6170C3B36E20283230303229
> sqlite>
>
> ---
> Active code page: 65001
>
> SQLite version 3.13.0 2016-05-18 10:57:30
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew.db
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Jap�n (2002)|4A6170C3B36E20283230303229
>
>
> Regards
>
> Simon
>
>
> -Original Message-
> From: sqlite-users-boun...@mailinglists.sqlite.org 
> [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Keith 
> Medcalf
> Sent: 13 July 2016 22:34
> To: SQLite mailing list 
> Subject: Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts 
> records with extended characters
>
>
> What console font are you using, and which codepage?  The default OEM 
> codepage is quite likely 437, and you may need to change it to 850.
>
> Codepage 437 is the original IBM ANSI OEM CodePage that contains line drawing 
> characters.  Codepage 850 is the multilingual codepage that has multilingual 
> characters in it.  I believe that the current shell is translating to MBCS 
> (ie, the Windows ACP, usually 1252 for Western European languages) so you 
> might want to try that codepage too.
>
> Also, the console font will affect the output.  The raster fonts do not 
> contain Unicode characters -- try using the Consolas or Lucida Console font 
> (both of which look like crap, though Consolas is the least crappy of the 
> two.)
>
>
>> One thing that concerns me though is that using windows command line
>> window with the sqlite3.exe v3.13.0 shell to interrogate a database
>> and display records, is that the display is corrupted - the database
>> is ok but display is not
>
>> SQLite version 3.13.0 2016-05-18 10:57:30 Enter ".help" for usage
>> hints.
>> Connected to a transient in-memory database.
>> Use ".open FILENAME" to reopen on a persistent database.
>> sqlite> .open test.restorednew.db
>> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
>> Jap n (2002)|4A6170C3B36E20283230303229
>> sqlite>
>
>> whereas version 3.8.6 does display the record ok. No change in select
>> output with 3.13.0 even after `chcp 65001`
>
>> And also tried the following
>> >or
>> >
>> >  (echo .output dump.sql && echo .dump) | sqlite3 old.db
>> >  sqlite3 -init dump.sql new.db
>>
>> But this sequence corrupted the database records
>>
>> SQLite version 3.13.0 2016-05-18 10:57:30 Enter ".help" for usage
>> hints.
>> Connected to a transient in-memory database.
>> Use ".open FILENAME" to reopen on a persistent database.
>> sqlite> .open test.restorednew2.db
>> sqlite> .tables
>> spellfix_metadata_titles  test-directories
>> spellfix_tag_titles   test-media_parts
>> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
>> Jap├│n

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-13 Thread dandl

> Good point, though personally I would weigh this in a different class of
> backward compatibility changes. 

I agree, but I have no evidence either way. You never really know what a
customer is doing until you change something they were using.

> I don't think changing this would be bad.
> But I also don't think a change is necessary.
> 
> Driving 51 in a zone posted 50 is also not in compliance (with a different
> standard, of course). Yet we violate that standard all the time.
> 
> The reality is that I'm not aware of a single platform that will fail to
> generate correct code for this (outside of treat all warnings as errors).

Again I agree, although again one never really knows. 

> Yes, it is a standards violation in the strictest sense. Yet it's not a
big
> deal given the number of successful deployments.
> 
> If anyone can demonstrate an implementation that uses this identifier in a
> way that is incompatible with SQLite, then it should be changed. Otherwise
it
> seems to me that disabling treat all warning as errors (or this one
warning
> in the impacted projects and files) is the least disruptive change for all
> concerned.

This is the core of this post, and the only part I disagree with. There are
corporate environments in which extremely tight control is maintained over
compliance and standards, and in which a decision as to how to treating
various warnings and errors raised by various development tools involves
multiple parties and multiple processes and multiple levels of approvals. It
is simply not possible to form a blanket opinion on exactly how disruptive
such a change would be in all possible users' environments; nor should one
try.

Regards
David M Bennett FACS

Andl - A New Database Language - andl.org






___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Menory leak/false positive

2016-07-13 Thread Igor Korot

Igor,

On Wed, Jul 13, 2016 at 8:23 PM, Igor Tandetnik  wrote:
> On 7/13/2016 8:12 PM, Igor Korot wrote:
>>
>> char *z = sqlite3_mprintf( query2.c_str(), tableName
>> );
>
>
> There is a bunch of calls to sqlite3_mprintf, but nary a call to
> sqlite3_free.

Thank you. That worked.
Now if anyone can explain why I have both "Memory leaks detected" and
"No leaks detected"...


> --
> Igor Tandetnik
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Menory leak/false positive

2016-07-13 Thread Igor Korot

Hi, ALL,
I am trying to create my software with MSVC 2010 and latest SQLite.

Because MSVC reported memory leaks, I tried VLD. Here is their output:

[quote]
Detected memory leaks!
Dumping objects ->
{158248} normal block at 0x011EA4B8, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{158164} normal block at 0x011EAAA0, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{153560} normal block at 0x011E8FD8, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{153479} normal block at 0x011AB100, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{152403} normal block at 0x011EA710, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{152143} normal block at 0x011AABD0, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{151376} normal block at 0x011AD190, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{150924} normal block at 0x011E8F78, 32 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{150182} normal block at 0x011AAB10, 56 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{150116} normal block at 0x011EA278, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{149345} normal block at 0x011EC398, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{149218} normal block at 0x011E8E10, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{148638} normal block at 0x011AACA8, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{148424} normal block at 0x011EA450, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{146249} normal block at 0x011E75E0, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{146189} normal block at 0x011E9100, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{145608} normal block at 0x011EA3E0, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{145545} normal block at 0x011ACA10, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{145073} normal block at 0x011AC9A0, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{145010} normal block at 0x011E74C0, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{144532} normal block at 0x011E7450, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{144484} normal block at 0x011E3CA8, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{143252} normal block at 0x011AAE80, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{143102} normal block at 0x011EAB28, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{142797} normal block at 0x011AAC40, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{142710} normal block at 0x011AC940, 32 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{142355} normal block at 0x011E7528, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{142313} normal block at 0x011E91A0, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{141529} normal block at 0x011E7350, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{141487} normal block at 0x011EB738, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{141269} normal block at 0x011EB6D0, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{141145} normal block at 0x011AB098, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{140691} normal block at 0x011AB030, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{140643} normal block at 0x011AD290, 32 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{140226} normal block at 0x011AD220, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{140108} normal block at 0x011E6938, 48 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{139867} normal block at 0x011AB188, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{139816} normal block at 0x011AD130, 32 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{139626} normal block at 0x011E3C40, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{139522} normal block at 0x011E3B50, 32 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
{139426} normal block at 0x011E3AE8, 40 bytes long.
 Data:  50 52 41 47 4D 41 20 66 6F 72 65 69 67 6E 5F 6B
{139174} normal block at 0x011AC358, 32 bytes long.
 Data:  50 52 41 47 4D 41 20 74 61 62 6C 65 5F 69 6E 66
Object dump complete.
No memory leaks detected.
Visual Leak Detector is now exiting.
The program '[2176] docview.exe: Native' has exited with code 0 (0x0).
[/quote]

And here is the code for the function:

[code]
int

Re: [sqlite] Menory leak/false positive

2016-07-13 Thread Igor Tandetnik


On 7/13/2016 8:12 PM, Igor Korot wrote:

char *z = sqlite3_mprintf( query2.c_str(), tableName );


There is a bunch of calls to sqlite3_mprintf, but nary a call to 
sqlite3_free.

--
Igor Tandetnik

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread Keith Medcalf


What console font are you using, and which codepage?  The default OEM codepage 
is quite likely 437, and you may need to change it to 850.

Codepage 437 is the original IBM ANSI OEM CodePage that contains line drawing 
characters.  Codepage 850 is the multilingual codepage that has multilingual 
characters in it.  I believe that the current shell is translating to MBCS (ie, 
the Windows ACP, usually 1252 for Western European languages) so you might want 
to try that codepage too.  

Also, the console font will affect the output.  The raster fonts do not contain 
Unicode characters -- try using the Consolas or Lucida Console font (both of 
which look like crap, though Consolas is the least crappy of the two.)


> One thing that concerns me though is that using windows command line
> window with the sqlite3.exe v3.13.0 shell to interrogate a database and
> display records, is that the display is corrupted - the database is ok but
> display is not
 
> SQLite version 3.13.0 2016-05-18 10:57:30
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew.db
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Jap�n (2002)|4A6170C3B36E20283230303229
> sqlite>
 
> whereas version 3.8.6 does display the record ok. No change in select
> output with 3.13.0 even after `chcp 65001`
 
> And also tried the following
> >or
> >
> >  (echo .output dump.sql && echo .dump) | sqlite3 old.db
> >  sqlite3 -init dump.sql new.db
> 
> But this sequence corrupted the database records
> 
> SQLite version 3.13.0 2016-05-18 10:57:30
> Enter ".help" for usage hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew2.db
> sqlite> .tables
> spellfix_metadata_titles  test-directories
> spellfix_tag_titles   test-media_parts
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Jap├│n (2002)|4A6170E2949CE294826E20283230303229
> sqlite>
> 
> The sequence I used
> (echo .output newdump2.sql && echo .dump) | sqlite3_v3.13.0
> test.original.db
> sqlite3_v3.13.0 -init newdump2.sql test.restorednew2.db
> 
> 
> Simon
> 
> -Original Message-
> From: sqlite-users-boun...@mailinglists.sqlite.org [mailto:sqlite-users-
> boun...@mailinglists.sqlite.org] On Behalf Of Clemens Ladisch
> Sent: 13 July 2016 18:26
> To: sqlite-users@mailinglists.sqlite.org
> Subject: Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file
> corrupts records with extended characters
> 
> S.Ajina wrote:
> > Can confirm that sqlite3.exe version 3.8.6 works ok restoring database
> > from a .dump dump.sql file using these commands
> >
> > echo .dump | sqlite3_v3.8.6   test.original.db   >  dump_v3.8.6.sql
> > sqlite3_v3.8.6   -init   dump_v3.8.6.sqltest.restored.v3.8.6.db
> >
> > Doing the same with the current version of sqlite3.exe (version
> > 3.13.0) corrupts the database records when there are extended
> > characters
> >
> > echo .dump | sqlite3_v3.13.0   test.original.db   >  dump_v3.13.0.sql
> > sqlite3_v3.13.0   -init   dump_v3.13.0.sqltest.restored.v3.13.0.db
> >
> > Release Notes show changes in this area in version 3.10.0 which may
> > have made the change Translate between MBCS and UTF8 when running in
> > cmd.exe on Windows
> 
> The old version of the sqlite3 shell assumes that screen and keyboard I/O
> could be done with UTF-8.  This assumption was wrong.
> 
> The new version converts screen and keyboard I/O between UTF-8 and the
> console's code page.  So the output redirection with > no longer uses UTF-
> 8.
> 
> To fix this, use the same mechanism for both output and input:
> 
>   sqlite3 old.db .dump > dump.sql
>   sqlite3 new.db < dump.sql
> 
> or
> 
>   (echo .output dump.sql && echo .dump) | sqlite3 old.db
>   sqlite3 -init dump.sql new.db
> 
> 
> Regards,
> Clemens
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
> 
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread S.Ajina

> What console font are you using, and which codepage?  The default OEM 
> codepage is quite likely 437, and you may need to change it to 850.
> 
> Codepage 437 is the original IBM ANSI OEM CodePage that contains line drawing 
> characters.  Codepage 850 is the multilingual codepage that has multilingual 
> characters in it.  I believe that the current shell is translating to MBCS 
> (ie, the Windows ACP, usually 1252 for Western European languages) so you 
> might want to try that codepage too.  

I must have switched to 65001 in that command line window - because the SELECT 
query does display correctly with code page 437 and code page 850 (default)

Results of tests

Active code page: 437

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.restorednew.db
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Japón (2002)|4A6170C3B36E20283230303229
sqlite>

--
Active code page: 850

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.restorednew.db
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Japón (2002)|4A6170C3B36E20283230303229
sqlite>

--
Active code page: 1252

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.restorednew.db
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Jap¢n (2002)|4A6170C3B36E20283230303229
sqlite>

---
Active code page: 65001

SQLite version 3.13.0 2016-05-18 10:57:30
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> .open test.restorednew.db
sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
Jap�n (2002)|4A6170C3B36E20283230303229


Regards 

Simon


-Original Message-
From: sqlite-users-boun...@mailinglists.sqlite.org 
[mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf
Sent: 13 July 2016 22:34
To: SQLite mailing list 
Subject: Re: [sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts 
records with extended characters


What console font are you using, and which codepage?  The default OEM codepage 
is quite likely 437, and you may need to change it to 850.

Codepage 437 is the original IBM ANSI OEM CodePage that contains line drawing 
characters.  Codepage 850 is the multilingual codepage that has multilingual 
characters in it.  I believe that the current shell is translating to MBCS (ie, 
the Windows ACP, usually 1252 for Western European languages) so you might want 
to try that codepage too.  

Also, the console font will affect the output.  The raster fonts do not contain 
Unicode characters -- try using the Consolas or Lucida Console font (both of 
which look like crap, though Consolas is the least crappy of the two.)


> One thing that concerns me though is that using windows command line 
> window with the sqlite3.exe v3.13.0 shell to interrogate a database 
> and display records, is that the display is corrupted - the database 
> is ok but display is not
 
> SQLite version 3.13.0 2016-05-18 10:57:30 Enter ".help" for usage 
> hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew.db
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Jap n (2002)|4A6170C3B36E20283230303229
> sqlite>
 
> whereas version 3.8.6 does display the record ok. No change in select 
> output with 3.13.0 even after `chcp 65001`
 
> And also tried the following
> >or
> >
> >  (echo .output dump.sql && echo .dump) | sqlite3 old.db
> >  sqlite3 -init dump.sql new.db
> 
> But this sequence corrupted the database records
> 
> SQLite version 3.13.0 2016-05-18 10:57:30 Enter ".help" for usage 
> hints.
> Connected to a transient in-memory database.
> Use ".open FILENAME" to reopen on a persistent database.
> sqlite> .open test.restorednew2.db
> sqlite> .tables
> spellfix_metadata_titles  test-directories
> spellfix_tag_titles   test-media_parts
> sqlite> SELECT path,hex(path) FROM "test-directories" WHERE id=68;
> Jap├│n (2002)|4A6170E2949CE294826E20283230303229
> sqlite>
> 
> The sequence I used
> (echo .output newdump2.sql && echo .dump) | sqlite3_v3.13.0 
> test.original.db
> sqlite3_v3.13.0 -init newdump2.sql test.restorednew2.db
> 
> 
> Simon
> 
> -Original Message-
> From: sqlite-users-boun...@mailinglists.sqlite.org 
> [mailto:sqlite-users- boun...@mailinglists.sqlite.org] On Behalf Of 
> Clemens Ladisch
> Sent: 13 July 2016 18:26
> To:

Re: [sqlite] Compiling on Xcode

2016-07-13 Thread Simon Slavin

On 14 Jul 2016, at 4:43am, Igor Korot  wrote:

> Right now my C Language option on the Xcode 5.1.1 is set to "GNU99".
> When using this option I am getting a lot of different warnings like:
> 
> Value Conversion Issue
> Implicit conversion loses integer precision.

Check the properties for the sqlite3.h and sqlite3.c files and make sure Xcode 
understands that they're C code.  It has a bad habit of assuming that .c files 
are C++ or Objective-C files.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Miroslav Rajcic

I've recorded the SQLs done to the original file (with all the tables, 
not the stripped one) which makes it corrupted, see below (I've removed 
"SELECT" queries from the list, assuming they are not relevant).


The issue is that it works OK when I feed it into sqlite command line 
tool with (it correctly SELECTs the item at the end):

sqlite3.exe test.db < sql_corrupt_no_select.txt

The difference may be compile flags between official sqlite3.exe and my 
version of sqlite lib, so I'll have to do more debugging here.


Regards,
  Miroslav

PRAGMA synchronous=FULL;
PRAGMA count_changes=OFF;
ALTER TABLE [notes] ADD [hash] VARCHAR(64) NULL;
ALTER TABLE [attachments] ADD [hash] VARCHAR(64) NULL;
ALTER TABLE [notes] ADD [hash_html] VARCHAR(64) NULL;
CREATE TABLE IF NOT EXISTS [anchors] (  [anc_id] INTEGER  PRIMARY KEY 
AUTOINCREMENT NOT NULL,  [note_id] VARCHAR(30)  NULL, [anc_name] 
VARCHAR(255)  NOT NULL,  [anc_offset] INTEGER NOT NULL );

CREATE INDEX IF NOT EXISTS [IDX_NOTE_HASH] ON [notes] (  [hash] DESC );
CREATE INDEX IF NOT EXISTS [IDX_NOTE_HASH_HTML] ON [notes] ( [hash_html] 
DESC );
CREATE TABLE IF NOT EXISTS [deletions] (  [del_id] INTEGER  NOT NULL 
PRIMARY KEY AUTOINCREMENT,  [note_id] VARCHAR(30) UNIQUE NOT NULL );

ALTER TABLE [tasks] ADD [script_path] TEXT NULL;
CREATE INDEX IF NOT EXISTS [IDX_DELETIONS_NOTE] ON [deletions] ( 
[note_id] DESC );
CREATE TABLE IF NOT EXISTS [deletions_attachments] (  [del_id] INTEGER 
PRIMARY KEY AUTOINCREMENT NOT NULL,  [att_code] VARCHAR(30) NOT NULL  );
CREATE INDEX IF NOT EXISTS [IDX_DELETIONS_ATT_NOTE] ON 
[deletions_attachments] (  [att_code] DESC );

ALTER TABLE [attachments] ADD [att_code] VARCHAR(30) NULL;
BEGIN EXCLUSIVE;
PRAGMA page_count;
PRAGMA freelist_count;
UPDATE notes_tree SET is_expanded=1 WHERE note_id='Q961n1K.d-H5Q9IZ.hNTbQ';
UPDATE notes SET date_created=0, date_modified=0, icon_type=-2, 
icon_info='', is_finished=0, is_readonly=0, is_template=0, 
syntax_highlight='', note_clone_id='', use_custom_txt_color=0, 
use_custom_bkg_color=0, use_custom_font=0, custom_txt_color='#00', 
custom_bkg_color='#00', custom_font='', use_custom_note_bkg_color=0, 
custom_note_bkg_color='#00'  WHERE note_id='Q961n1K.d-H5Q9IZ.hNTbQ';

UPDATE notes_tree SET is_expanded=1 WHERE note_id='F3N3YO3MJMeqBAy7kJOYIA';
UPDATE notes SET date_created=0, date_modified=1317743245, icon_type=0, 
icon_info='blog', is_finished=0, is_readonly=0, is_template=0, 
syntax_highlight='', note_clone_id='', use_custom_txt_color=0, 
use_custom_bkg_color=0, use_custom_font=0, custom_txt_color='#00', 
custom_bkg_color='#00', custom_font='', use_custom_note_bkg_color=0, 
custom_note_bkg_color='#00'  WHERE note_id='F3N3YO3MJMeqBAy7kJOYIA';

ROLLBACK;
SELECT * FROM images WHERE note_id="2O7Ej89J3K8Fax5OedEiQQ" ;

On 13.7.2016. 13:05, Richard Hipp wrote:

On 7/13/16, Miroslav Rajcic  wrote:
Issue can be reproduced on Windows and Mac 

Can you please send the steps needed to reproduce the problem?


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Compiling on Xcode

2016-07-13 Thread Igor Korot

Hi, ALL,
Right now my C Language option on the Xcode 5.1.1 is set to "GNU99".
When using this option I am getting a lot of different warnings like:

Value Conversion Issue
Implicit conversion loses integer precision.

I know its just a warning, but I prefer the code to be compiled clean.
I would guess that I need a change the option to get a clean compile.

Which one I should use?

Thank you.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Bug: SQLite's include guards are reserved identifiers

2016-07-13 Thread Scott Robison

On Wed, Jul 13, 2016 at 6:57 PM, dandl  wrote:

> > Good point, though personally I would weigh this in a different class of
> > backward compatibility changes.
>
> I agree, but I have no evidence either way. You never really know what a
> customer is doing until you change something they were using.
>

Yes. But we're not talking about SQLite functionality. We're talking about
an include guard. Well, several include guards in the case of the
amalgamation, but defined macros that aren't used anywhere other than to
protect against multiple inclusion. If anyone is using a guard to detect
SQLite availability, what is going to go wrong? A change to the include
guard macro would mean incorrectly detect SQLite is not available (but it
really is because the guard changed) and try to compile some alternative
piece of code (which could be a simple #error directive, or some
alternative database management code that doesn't depend on SQLite). In
either case, SQLite isn't going to start doing something different than it
did previously (which would be a bad backward compatibility change).

> > I don't think changing this would be bad.
> > But I also don't think a change is necessary.
> >
> > Driving 51 in a zone posted 50 is also not in compliance (with a
> different
> > standard, of course). Yet we violate that standard all the time.
> >
> > The reality is that I'm not aware of a single platform that will fail to
> > generate correct code for this (outside of treat all warnings as errors).
>
> Again I agree, although again one never really knows.
>

You're right, no one knows. However, given long standing practice not just
by SQLite but by *many* libraries from *many* vendors, it is unlikely that
any serious compiler vendor is going to start refusing to accept this
technically invalid yet common practice. The users would be up in arms that
they can't compile code that works every place else. Even the most pedantic
environments that complain about various problematic constructs still allow
the constructs.

> > Yes, it is a standards violation in the strictest sense. Yet it's not a
> big
> > deal given the number of successful deployments.
> >
> > If anyone can demonstrate an implementation that uses this identifier in
> a
> > way that is incompatible with SQLite, then it should be changed.
> Otherwise
> it
> > seems to me that disabling treat all warning as errors (or this one
> warning
> > in the impacted projects and files) is the least disruptive change for
> all
> > concerned.
>
> This is the core of this post, and the only part I disagree with. There are
> corporate environments in which extremely tight control is maintained over
> compliance and standards, and in which a decision as to how to treating
> various warnings and errors raised by various development tools involves
> multiple parties and multiple processes and multiple levels of approvals.
> It
> is simply not possible to form a blanket opinion on exactly how disruptive
> such a change would be in all possible users' environments; nor should one
> try.
>

I'm not sure how this is a disagreement. I said it probably shouldn't be
changed unless or until it is identified to be an actual problem vs a
theoretical problem. Warnings are not errors (in the absence of a switch
promoting warnings to errors). If an environment is identified that really
treats this as an error, that would be the time to consider it.

It is imminently possible to form an opinion on this: unless and until
someone demonstrates an actual problem, a change should not be necessary. I
won't be bothered whether or not a change is made. But to suggest someone
can't "try" to have an opinion on such a minor thing (and it is minor, or
even infinitesimally significant, given the billions of successful
installations of SQLite around the world) seems odd to me. Decisions are
made all the time to try to determine how critical a "bug" or "feature" or
"change" is and what impact it will have on different classes of users. In
fact, that's at the root of this discussion. Would changing the spelling of
an include guard (where _ is just another letter in the set of letters)
improve the product or hurt existing users of the product? It might require
some people to change a line of code from:

#if defined(_SQLITE3_H_)

to

#if defined(_SQLITE3_H_) || defined(SQLITE3_H_INCLUDED)

or lines to that effect.

If all you meant is "you can't know how disruptive it will be across all
users" then sure, you are correct. But we still have to try to quantify
what might break with any change and quantify the utility of the change. If
anything, it is a statement that allows one to easily argue for not making
a change to an include guard where the code is currently working for so
many developers / deployments.

>
> Regards
> David M Bennett FACS
>
> Andl - A New Database Language - andl.org
>
>
>
>
>
>
> ___
> sqlite-users mailing list
>

Re: [sqlite] Possible index corruption

2016-07-13 Thread Miroslav Rajcic

Good news: actually those SQL commands perfectly reproduce the issue, I 
just forgot to reload the database before checking the issue with 
"SELECT" query.


I'll now ask a customer for a permission to send you a document off-list.

Regards,
  Miroslav

On 14.7.2016. 7:24, Miroslav Rajcic wrote:
I've recorded the SQLs done to the original file (with all the tables, 
not the stripped one) which makes it corrupted, see below (I've 
removed "SELECT" queries from the list, assuming they are not relevant).


The issue is that it works OK when I feed it into sqlite command line 
tool with (it correctly SELECTs the item at the end):

sqlite3.exe test.db < sql_corrupt_no_select.txt

The difference may be compile flags between official sqlite3.exe and 
my version of sqlite lib, so I'll have to do more debugging here.


Regards,
  Miroslav

PRAGMA synchronous=FULL;
PRAGMA count_changes=OFF;
ALTER TABLE [notes] ADD [hash] VARCHAR(64) NULL;
ALTER TABLE [attachments] ADD [hash] VARCHAR(64) NULL;
ALTER TABLE [notes] ADD [hash_html] VARCHAR(64) NULL;
CREATE TABLE IF NOT EXISTS [anchors] (  [anc_id] INTEGER  PRIMARY KEY 
AUTOINCREMENT NOT NULL,  [note_id] VARCHAR(30)  NULL, [anc_name] 
VARCHAR(255)  NOT NULL,  [anc_offset] INTEGER NOT NULL );

CREATE INDEX IF NOT EXISTS [IDX_NOTE_HASH] ON [notes] (  [hash] DESC );
CREATE INDEX IF NOT EXISTS [IDX_NOTE_HASH_HTML] ON [notes] ( 
[hash_html] DESC );
CREATE TABLE IF NOT EXISTS [deletions] (  [del_id] INTEGER  NOT NULL 
PRIMARY KEY AUTOINCREMENT,  [note_id] VARCHAR(30) UNIQUE NOT NULL );

ALTER TABLE [tasks] ADD [script_path] TEXT NULL;
CREATE INDEX IF NOT EXISTS [IDX_DELETIONS_NOTE] ON [deletions] ( 
[note_id] DESC );
CREATE TABLE IF NOT EXISTS [deletions_attachments] (  [del_id] INTEGER 
PRIMARY KEY AUTOINCREMENT NOT NULL,  [att_code] VARCHAR(30) NOT NULL  );
CREATE INDEX IF NOT EXISTS [IDX_DELETIONS_ATT_NOTE] ON 
[deletions_attachments] (  [att_code] DESC );

ALTER TABLE [attachments] ADD [att_code] VARCHAR(30) NULL;
BEGIN EXCLUSIVE;
PRAGMA page_count;
PRAGMA freelist_count;
UPDATE notes_tree SET is_expanded=1 WHERE 
note_id='Q961n1K.d-H5Q9IZ.hNTbQ';
UPDATE notes SET date_created=0, date_modified=0, icon_type=-2, 
icon_info='', is_finished=0, is_readonly=0, is_template=0, 
syntax_highlight='', note_clone_id='', use_custom_txt_color=0, 
use_custom_bkg_color=0, use_custom_font=0, custom_txt_color='#00', 
custom_bkg_color='#00', custom_font='', 
use_custom_note_bkg_color=0, custom_note_bkg_color='#00'  WHERE 
note_id='Q961n1K.d-H5Q9IZ.hNTbQ';
UPDATE notes_tree SET is_expanded=1 WHERE 
note_id='F3N3YO3MJMeqBAy7kJOYIA';
UPDATE notes SET date_created=0, date_modified=1317743245, 
icon_type=0, icon_info='blog', is_finished=0, is_readonly=0, 
is_template=0, syntax_highlight='', note_clone_id='', 
use_custom_txt_color=0, use_custom_bkg_color=0, use_custom_font=0, 
custom_txt_color='#00', custom_bkg_color='#00', 
custom_font='', use_custom_note_bkg_color=0, 
custom_note_bkg_color='#00'  WHERE note_id='F3N3YO3MJMeqBAy7kJOYIA';

ROLLBACK;
SELECT * FROM images WHERE note_id="2O7Ej89J3K8Fax5OedEiQQ" ;

On 13.7.2016. 13:05, Richard Hipp wrote:

On 7/13/16, Miroslav Rajcic  wrote:
Issue can be reproduced on Windows and Mac 

Can you please send the steps needed to reproduce the problem?


___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Document ommision bind-parameter description

2016-07-13 Thread Paul Sanderson

There is a minor ommision on the BNF page of the database

http://www.sqlite.org/docsrc/doc/trunk/art/syntax/all-bnf.html#bind-parameter

In the expr section bind-parameter is a dangling hyper link



Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
-Forensic Toolkit for SQLite
email from a work address for a fully functional demo licence
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Document ommision bind-parameter description

2016-07-13 Thread Richard Hipp

On 7/13/16, Paul Sanderson  wrote:
> There is a minor ommision on the BNF page of the database
>
> http://www.sqlite.org/docsrc/doc/trunk/art/syntax/all-bnf.html#bind-parameter
>
> In the expr section bind-parameter is a dangling hyper link

That BNF version of the grammar is unmaintained and is obsolete in
multiple respects.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Richard Hipp

Off-list reply

On 7/13/16, Miroslav Rajcic  wrote:
>
> Note that I had to delete other tables to protect customer info.

You did not seem to enable "PRAGMA secure_delete" before deleting the
other tables.  Hence, much of the content is still in the file, on the
freelist.

You might want to take down your two sample database files.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Richard Hipp

On 7/13/16, Miroslav Rajcic  wrote:
> Issue can be reproduced on Windows and Mac

Can you please send the steps needed to reproduce the problem?

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Chris Locke

*everyone rushes to download the files to have a nose*

On Wed, Jul 13, 2016 at 12:02 PM, Richard Hipp  wrote:

> Off-list reply
>
> On 7/13/16, Miroslav Rajcic  wrote:
> >
> > Note that I had to delete other tables to protect customer info.
>
> You did not seem to enable "PRAGMA secure_delete" before deleting the
> other tables.  Hence, much of the content is still in the file, on the
> freelist.
>
> You might want to take down your two sample database files.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] new version

2016-07-13 Thread Bill Meng

I have an old version of SQLite 3.8.7 for windows and downloaded the new 
binaries v 3.13.0 in the zip format which contained the 2 unzipped files 
.def and .dll .


However there was nothing informing me about the installation procedure.

Can someone help?

Thanks
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] small website typo

2016-07-13 Thread Paul Joyce

https://www.sqlite.org/rtree.html has two sections numbered 3.3



Regards, Paul

Paul Joyce
Chief Technology Officer
pjo...@we-do-it.com
m: +61 450 066 131
www.we-do-IT.com

we-do-IT Pty Ltd
Level 12, 200 Queen Street
Melbourne VIC 3000
AUSTRALIA
ABN 26 071 972 891
[http://www.we-do-it.com/images/footerlogo.jpg]
ISO 9001:2008
Certified for the provision of
IT based Consulting
Training and
Product Development Services
[http://www.we-do-it.com/images/iso9001certified.jpg]

This email remains the property of we-do-IT Pty Ltd and is subject to the 
jurisdiction of section 70 of the Australian Crimes Act 1914.
If you have received this email in error, you are requested to contact the 
sender and delete the email.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Document ommision bind-parameter description

2016-07-13 Thread Paul Sanderson

Ok Thank you
Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
http://sandersonforensics.com/forum/content.php?195-SQLite-Forensic-Toolkit
-Forensic Toolkit for SQLite
email from a work address for a fully functional demo licence


On 13 July 2016 at 12:20, Richard Hipp  wrote:
> On 7/13/16, Paul Sanderson  wrote:
>> There is a minor ommision on the BNF page of the database
>>
>> http://www.sqlite.org/docsrc/doc/trunk/art/syntax/all-bnf.html#bind-parameter
>>
>> In the expr section bind-parameter is a dangling hyper link
>
> That BNF version of the grammar is unmaintained and is obsolete in
> multiple respects.
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Miroslav Rajcic


Hi Richard,

I'm aware of the fact, but Daniel Hertrich, who is the customer in 
question (he replied in this thread), looked into the file with hex 
editor before giving the approval.


Regards,
  Miroslav

On 13.7.2016. 13:02, Richard Hipp wrote:

Off-list reply

On 7/13/16, Miroslav Rajcic  wrote:

Note that I had to delete other tables to protect customer info.

You did not seem to enable "PRAGMA secure_delete" before deleting the
other tables.  Hence, much of the content is still in the file, on the
freelist.

You might want to take down your two sample database files.



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Miroslav Rajcic

No big deal, we were aware of the fact before my post and I got a green 
light from Daniel.


It is that "VACUUM" of the database would cause the issue to go away, so 
we choose to send it as it is.


Regards,

  Miroslav


On 13.7.2016. 16:13, Richard Hipp wrote:

On 7/13/16, Chris Locke  wrote:

*everyone rushes to download the files to have a nose*

Yeah - I messed up on that "off-list" reply.  I have already grovelled
before Miroslav.  Sorry.



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] [Windows] 3.13.0 recreate db from .dump file corrupts records with extended characters

2016-07-13 Thread S.Ajina

On windows platform, the following commands using windows command line prompt 
and sqlite3.exe worked with old versions of sqlite3.exe
Can confirm that sqlite3.exe version 3.8.6 works ok restoring database from a 
.dump dump.sql file using these commands

echo .dump | sqlite3_v3.8.6   test.original.db   >  dump_v3.8.6.sql
sqlite3_v3.8.6   -init   dump_v3.8.6.sqltest.restored.v3.8.6.db

Doing the same with the current version of sqlite3.exe (version 3.13.0) 
corrupts the database records when there are extended characters

echo .dump | sqlite3_v3.13.0   test.original.db   >  dump_v3.13.0.sql
sqlite3_v3.13.0   -init   dump_v3.13.0.sqltest.restored.v3.13.0.db

Could not find any related bug on the Bugs List
Release Notes show changes in this area in version 3.10.0 which may have made 
the change
Translate between MBCS and UTF8 when running in cmd.exe on Windows

I have no access to the old versions downloads to establish at what version of 
sqlite3.exe the problem came

The closest thread in this list archive is this one
.DUMP output compatibility
http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2016-May/066540.html

Please confirm if this is a bug or a change – but if it is a change we need 
advice on how for the common user to achieve the simple method of dump and 
recreate 

running sqldiff to compare the two restored database versions and to compare 
with the original db file, shows discrepancies like these
This is doing a two-way set of compares

Diffs1
UPDATE "test-directories" SET path='Hidden (Cach├®) (2005)' WHERE id=56;
UPDATE "test-directories" SET path='Jap├│n (2002)' WHERE id=68;
UPDATE "test-directories" SET path='Caf├® de Flore (2011)' WHERE id=94;
UPDATE "test-directories" SET path='WALL┬ÀE (2008)' WHERE id=118;
UPDATE "test-directories" SET path='Maurice B├®jart - L''Amour, La Danse (Best 
Of)' WHERE id=158;
UPDATE "test-directories" SET path='Struktura kryszta┼éu (1969)' WHERE id=216;
UPDATE "test-directories" SET path='Pora umiera─ç (2007)' WHERE id=218;
UPDATE "test-directories" SET path='Popio┼éy - The Ashes (1965)' WHERE id=219;
UPDATE "test-directories" SET path='Podw├│jne ┼╝ycie Weroniki (1991)' WHERE 
id=220;
UPDATE "test-directories" SET path='Cz┼éowiek z marmuru (1977)' WHERE id=222;
UPDATE "test-media_parts" SET file='\\nas-london-1\Qmultimedia\Movies\Caf├® de 
Flore (2011)\Caf├® de Flore (2011).mp4' WHERE id=290;
UPDATE "test-media_parts" SET file='\\nas-london-1\Qmultimedia\Movies\WALL┬ÀE 
(2008)\WALL┬ÀE (2008).mp4' WHERE id=392;
UPDATE "test-media_parts" SET file='\\nas-london-1\Qmultimedia\Movies\Maurice 
B├®jart - L''Amour, La Danse (Best Of)\Maurice B├®jart - L''Amour, La Danse 
(Best Of).mp4' WHERE id=508;

Diff2
UPDATE "test-directories" SET path='Hidden (Caché) (2005)' WHERE id=56;
UPDATE "test-directories" SET path='Japón (2002)' WHERE id=68;
UPDATE "test-directories" SET path='Café de Flore (2011)' WHERE id=94;
UPDATE "test-directories" SET path='WALL·E (2008)' WHERE id=118;
UPDATE "test-directories" SET path='Maurice Béjart - L''Amour, La Danse (Best 
Of)' WHERE id=158;
UPDATE "test-directories" SET path='Struktura kryształu (1969)' WHERE id=216;
UPDATE "test-directories" SET path='Pora umierać (2007)' WHERE id=218;
UPDATE "test-directories" SET path='Popioły - The Ashes (1965)' WHERE id=219;
UPDATE "test-directories" SET path='Podwójne życie Weroniki (1991)' WHERE 
id=220;
UPDATE "test-directories" SET path='Człowiek z marmuru (1977)' WHERE id=222;
UPDATE "test-media_parts" SET file='\\nas-london-1\Qmultimedia\Movies\Café de 
Flore (2011)\Café de Flore (2011).mp4' WHERE id=290;
UPDATE "test-media_parts" SET file='\\nas-london-1\Qmultimedia\Movies\WALL·E 
(2008)\WALL·E (2008).mp4' WHERE id=392;
UPDATE "test-media_parts" SET file='\\nas-london-1\Qmultimedia\Movies\Maurice 
Béjart - L''Amour, La Danse (Best Of)\Maurice Béjart - L''Amour, La Danse (Best 
Of).mp4' WHERE id=508;

Thank You

Simon

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] new version

2016-07-13 Thread Stephen Chrzanowski

There isn't really an installation.  The DLL would need to be in either
your Windows\System32 directory (Or some PATH Windows knows about), or in
the same directory as your EXE.

The other option, if you're building SQLite into your application, is get
the Amalgamation and build your product off that.

On Tue, Jul 12, 2016 at 9:05 PM, Bill Meng  wrote:

> I have an old version of SQLite 3.8.7 for windows and downloaded the new
> binaries v 3.13.0 in the zip format which contained the 2 unzipped files
> .def and .dll .
>
> However there was nothing informing me about the installation procedure.
>
> Can someone help?
>
> Thanks
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Possible index corruption

2016-07-13 Thread Richard Hipp

On 7/13/16, Chris Locke  wrote:
> *everyone rushes to download the files to have a nose*

Yeah - I messed up on that "off-list" reply.  I have already grovelled
before Miroslav.  Sorry.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] small website typo

2016-07-13 Thread Richard Hipp

On 7/12/16, Paul Joyce  wrote:
> https://www.sqlite.org/rtree.html has two sections numbered 3.3

Thanks.

To fix this I converted the r-tree document to the new format style.
See https://www.sqlite.org/draft/rtree.html for a draft.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

39 matches

Mail list logo