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

On 2016-07-12 9:32 PM, Cory Nelson wrote: On Fri, Jul 8, 2016 at 6:56 PM, Daniel Seither wrote: Using clang 3.8 with -Wreserved-id-macro (enabled by -Weverything), I just noticed that SQLite uses include guards with a leading underscore, for example _SQLITE3_H_ in the amalgamation. According to

Re: [sqlite] Possible index corruption

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'

Re: [sqlite] Possible index corruption

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 co

Re: [sqlite] Compiling on Xcode

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 sql

[sqlite] Compiling on Xcode

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 gu

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

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 usin

Re: [sqlite] Menory leak/false positive

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 worke

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

> 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

Re: [sqlite] Menory leak/false positive

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 sqlit

[sqlite] Menory leak/false positive

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

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

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? Th

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 multil

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 c

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

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 ver

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

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

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

> 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 s

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

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 enco

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

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

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

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

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 fourt

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

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. _

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

> 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

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

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 weig

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

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 cha

Re: [sqlite] Possible index corruption

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? __

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 S

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

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

Re: [sqlite] Possible index corruption

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:

Re: [sqlite] Possible index corruption

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 wro

Re: [sqlite] small website typo

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 _

Re: [sqlite] Possible index corruption

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 sq

Re: [sqlite] new version

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 th

Re: [sqlite] Possible index corruption

*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" bef

[sqlite] new version

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] small website typo

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

Re: [sqlite] Document ommision bind-parameter description

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

Re: [sqlite] Document ommision bind-parameter description

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 ob

Re: [sqlite] Possible index corruption

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:/

Re: [sqlite] Possible index corruption

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 do

[sqlite] Document ommision bind-parameter description

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