> 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.sql    test.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.sql    test.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

Reply via email to