Re: [sqlite] Strange Corruption

2010-11-20 Thread Pirmin Walthert
No, this is definitely not the reason in my case as I can reproduce this 
issue on every 3.7.2/3.7.3 machine I've tested after copying the 
database file (and only the database file) to these machines.

Am 15.11.2010 15:41, schrieb Kirk Clemons:
 Not sure if it helps but I would see this quite frequently when an old 
 journal file would be left behind in the same directory as the backup 
 database. This could be why making a change to the database such as vacuum 
 would prevent the corruption.
 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

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


Re: [sqlite] Strange Corruption

2010-11-17 Thread Pirmin Walthert
.dump (3.6.23.1) and afterwards sqlite3 /tmp/new.db  /tmp/dump.sql 
with 3.7.2 worked and fixed the .backup problem (as expected).

As I've already downgraded sqlite3 in our new firmware and patched the 
live-systems that were running with the new firmware I'll only have one 
machine to check whether the error comes back or not... So maybe I'll 
not be able to give feedback for a few weeks (as I can not enforce errors).

However: if the error will not come back and could have to do with an 
already existing error in the database it would be quite interesting to 
know why integrity_check doesn't find the error before making a backup. 
(What means that a bug exists in any case: either in PRAGMA 
integrity_check or in the backup function).

---
Pirmin Walthert

Am 16.11.2010 14:22, schrieb Black, Michael (IS):
 Sorry, I meant .dump

 Given what you're describing I think it's worth finding out if you've found 
 some bug in 3.7.2.
 The docs say 3.7.2 fixed a long-standing corruption bug.  I don't know if 
 that's related to this or not but sounds suspiciously close.

 So...

 #1 .dump the database
 #2 .import in into 3.7.2
 #3 Run for a few days and see if you still get your backup problem.

 If still corrupt try 3.7.3

 If it works then it sounds like the database was corrupt already and 3.7.2 
 just hits it.


 Michael D. Black
 Senior Scientist
 Advanced Analytics Directorate
 Northrop Grumman Information Systems


 

 From: sqlite-users-boun...@sqlite.org on behalf of Pirmin Walthert
 Sent: Tue 11/16/2010 7:09 AM
 To: sqlite-users@sqlite.org
 Subject: Re: [sqlite] EXTERNAL:Re: Strange Corruption



 Well indeed it wasn't 3.7.X that created the database originally. But it
 was always 3.7.2 that made the INSERTS/UPDATES that lead to the state in
 which the database couldn't be backed up anymore. So what do you mean in
 fact: 3.7.X maybe can't handle database structures created with older
 versions?!

 Even after doing a vacuum which fixed the bug I had the same errors
 again on the machines with 3.7.2 after a few days (after other
 INSERTS/UPDATES).

 About the thing I should test:

 There is no command called .export it seems?!

 But I think that I don't even have to test the thing you propose, as it
 will work almost for sure =  like already stated several times one
 little tiny tiny tiny change already fixes the error. As an
 .export/.import will change some bits for sure this will already change
 the situation!

 Am 16.11.2010 13:53, schrieb Black, Michael (IS):
 I thought of another test you should try.

 Do an .export of your original database using 3.6.23.1 and .import it 
 (constructing a new database).  Then try your backup.

 If that works then you're just seeing corruption in the original database 
 that 3.6.23.1 handles (since it created it).

 If it doesn't work import into 3.7.3 and test backup again.

 If it doesn't work then try cutting the SQL in half until it does work.  
 Maybe you'll finally get a small enough size you can post.



 Michael D. Black
 Senior Scientist
 Advanced Analytics Directorate
 Northrop Grumman Information Systems


 

 From: sqlite-users-boun...@sqlite.org on behalf of Pirmin Walthert
 Sent: Tue 11/16/2010 6:27 AM
 To: sqlite-users@sqlite.org
 Subject: EXTERNAL:Re: [sqlite] Strange Corruption



 No, this is definitely not the reason in my case as I can reproduce this
 issue on every 3.7.2/3.7.3 machine I've tested after copying the
 database file (and only the database file) to these machines.





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




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

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


Re: [sqlite] Strange Corruption

2010-11-16 Thread Kirk Clemons
Not sure if it helps but I would see this quite frequently when an old journal 
file would be left behind in the same directory as the backup database. This 
could be why making a change to the database such as vacuum would prevent the 
corruption.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Strange Corruption

2010-11-16 Thread Pirmin Walthert
No, this is definitely not the reason in my case as I can reproduce this 
issue on every 3.7.2/3.7.3 machine I've tested after copying the 
database file (and only the database file) to these machines.

Am 15.11.2010 15:41, schrieb Kirk Clemons:
 Not sure if it helps but I would see this quite frequently when an old 
 journal file would be left behind in the same directory as the backup 
 database. This could be why making a change to the database such as vacuum 
 would prevent the corruption.
 ___
 sqlite-users mailing list
 sqlite-users@sqlite.org
 http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

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


Re: [sqlite] Strange Corruption

2010-11-16 Thread Black, Michael (IS)
Sorry, I meant .dump
 
Given what you're describing I think it's worth finding out if you've found 
some bug in 3.7.2.
The docs say 3.7.2 fixed a long-standing corruption bug.  I don't know if 
that's related to this or not but sounds suspiciously close.
 
So...
 
#1 .dump the database
#2 .import in into 3.7.2
#3 Run for a few days and see if you still get your backup problem.
 
If still corrupt try 3.7.3
 
If it works then it sounds like the database was corrupt already and 3.7.2 just 
hits it.
 
 
Michael D. Black
Senior Scientist
Advanced Analytics Directorate
Northrop Grumman Information Systems
 



From: sqlite-users-boun...@sqlite.org on behalf of Pirmin Walthert
Sent: Tue 11/16/2010 7:09 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] EXTERNAL:Re: Strange Corruption



Well indeed it wasn't 3.7.X that created the database originally. But it
was always 3.7.2 that made the INSERTS/UPDATES that lead to the state in
which the database couldn't be backed up anymore. So what do you mean in
fact: 3.7.X maybe can't handle database structures created with older
versions?!

Even after doing a vacuum which fixed the bug I had the same errors
again on the machines with 3.7.2 after a few days (after other
INSERTS/UPDATES).

About the thing I should test:

There is no command called .export it seems?!

But I think that I don't even have to test the thing you propose, as it
will work almost for sure = like already stated several times one
little tiny tiny tiny change already fixes the error. As an
.export/.import will change some bits for sure this will already change
the situation!

Am 16.11.2010 13:53, schrieb Black, Michael (IS):
 I thought of another test you should try.

 Do an .export of your original database using 3.6.23.1 and .import it 
 (constructing a new database).  Then try your backup.

 If that works then you're just seeing corruption in the original database 
 that 3.6.23.1 handles (since it created it).

 If it doesn't work import into 3.7.3 and test backup again.

 If it doesn't work then try cutting the SQL in half until it does work.  
 Maybe you'll finally get a small enough size you can post.



 Michael D. Black
 Senior Scientist
 Advanced Analytics Directorate
 Northrop Grumman Information Systems


 

 From: sqlite-users-boun...@sqlite.org on behalf of Pirmin Walthert
 Sent: Tue 11/16/2010 6:27 AM
 To: sqlite-users@sqlite.org
 Subject: EXTERNAL:Re: [sqlite] Strange Corruption



 No, this is definitely not the reason in my case as I can reproduce this
 issue on every 3.7.2/3.7.3 machine I've tested after copying the
 database file (and only the database file) to these machines.





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

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


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


Re: [sqlite] Strange Corruption

2010-11-16 Thread Pirmin Walthert
.dump (3.6.23.1) and afterwards sqlite3 /tmp/new.db  /tmp/dump.sql 
with 3.7.2 worked and fixed the .backup problem (as expected).

As I've already downgraded sqlite3 in our new firmware and patched the 
live-systems that were running with the new firmware I'll only have one 
machine to check whether the error comes back or not... So maybe I'll 
not be able to give feedback for a few weeks (as I can not enforce errors).

However: if the error will not come back and could have to do with an 
already existing error in the database it would be quite interesting to 
know why integrity_check doesn't find the error before making a backup. 
(What means that a bug exists in any case: either in PRAGMA 
integrity_check or in the backup function).

---
Pirmin Walthert

Am 16.11.2010 14:22, schrieb Black, Michael (IS):
 Sorry, I meant .dump

 Given what you're describing I think it's worth finding out if you've found 
 some bug in 3.7.2.
 The docs say 3.7.2 fixed a long-standing corruption bug.  I don't know if 
 that's related to this or not but sounds suspiciously close.

 So...

 #1 .dump the database
 #2 .import in into 3.7.2
 #3 Run for a few days and see if you still get your backup problem.

 If still corrupt try 3.7.3

 If it works then it sounds like the database was corrupt already and 3.7.2 
 just hits it.


 Michael D. Black
 Senior Scientist
 Advanced Analytics Directorate
 Northrop Grumman Information Systems


 

 From:sqlite-users-boun...@sqlite.org  on behalf of Pirmin Walthert
 Sent: Tue 11/16/2010 7:09 AM
 To:sqlite-users@sqlite.org
 Subject: Re: [sqlite] EXTERNAL:Re: Strange Corruption



 Well indeed it wasn't 3.7.X that created the database originally. But it
 was always 3.7.2 that made the INSERTS/UPDATES that lead to the state in
 which the database couldn't be backed up anymore. So what do you mean in
 fact: 3.7.X maybe can't handle database structures created with older
 versions?!

 Even after doing a vacuum which fixed the bug I had the same errors
 again on the machines with 3.7.2 after a few days (after other
 INSERTS/UPDATES).

 About the thing I should test:

 There is no command called .export it seems?!

 But I think that I don't even have to test the thing you propose, as it
 will work almost for sure =  like already stated several times one
 little tiny tiny tiny change already fixes the error. As an
 .export/.import will change some bits for sure this will already change
 the situation!

 Am 16.11.2010 13:53, schrieb Black, Michael (IS):
 I thought of another test you should try.

 Do an .export of your original database using 3.6.23.1 and .import it 
 (constructing a new database).  Then try your backup.

 If that works then you're just seeing corruption in the original database 
 that 3.6.23.1 handles (since it created it).

 If it doesn't work import into 3.7.3 and test backup again.

 If it doesn't work then try cutting the SQL in half until it does work.  
 Maybe you'll finally get a small enough size you can post.



 Michael D. Black
 Senior Scientist
 Advanced Analytics Directorate
 Northrop Grumman Information Systems


 

 From:sqlite-users-boun...@sqlite.org  on behalf of Pirmin Walthert
 Sent: Tue 11/16/2010 6:27 AM
 To:sqlite-users@sqlite.org
 Subject: EXTERNAL:Re: [sqlite] Strange Corruption



 No, this is definitely not the reason in my case as I can reproduce this
 issue on every 3.7.2/3.7.3 machine I've tested after copying the
 database file (and only the database file) to these machines.





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



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

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