On 02/09/2011 08:17 PM, Dennis Geldhof wrote: > I checked some things for the attached database. It is created with > sqlite version 3.6.3 or 3.6.23.1 with the help of the system.data.sqlite > wrapper. The header displays (with the ./showdb) version 3.7.4, so it is > opened and changed with a database viewer tool. Before executing the > "query" the database integrity is OK in both 3.6.23.1 and 3.7.4, after > executing it is OK for 3.6.23.1 but malformed for 3.7.4. The "query" is > executed using the system.data.sqlite wrapper (sqlite v3.6.23.1). It > does not matter if the database was encrypted while executing the > "query", the result stays the same.
Thanks for doing this. It sounds like it is worth trying to figure out what makes this db special. Are you able to make the test.db3 database available for download or mail it to me directly? This mailing list strips out attachments. Dan. > > The "query" is used to change some table structures in the database and > executes the following actions on the database; > BEGIN TRANSACTION; > > ALTER TABLE [A] RENAME TO [TMP_A] > ALTER TABLE [B] RENAME TO [TMP_B] > > CREATE TABLE [A] (); -- where A is a new table, stripped columns > CREATE TABLE [B] (); -- where B is a new table, stripped columns > CREATE TABLE [C] (); -- stripped columns > > INSERT INTO [A] > SELECT > (SELECT [ColumnA] FROM [D] WHERE [ColumnB] = [TMP_A].[ColumnB]), > (SELECT [ColumnC] FROM [TMP_B] WHERE ([ColumnD] = > [TMP_A].[ColumnD]) AND (NOT [ColumnC] ISNULL) LIMIT 1), > -- stripped more columns > FROM [TMP_A]; > > -- stripped some more INSERT INTO [] SELECT > -- stripped some UPDATE > > DROP TABLE [TMP_A]; > DROP TABLE [TMP_B]; > DROP TABLE [D]; > DROP TABLE [E]; > DROP TABLE [F]; > > COMMIT TRANSACTION; > > > When omitting the DROP TABLE [TMP_B], the 3.7.4 does not detect > corruption directly, until some more updates are executed on the > database. > > When the database before the "query" is .dump-ed to file, and .read into > a new 3.6.23.1 database, the corruption does not become visible after > the "query". So it seems to be in the header of that database. > > I didn't find a way yet to reproduce the issue with a "clean" database. > Only way I can reproduce it is with some of the database, like the > test.db3. So I'm running out of ideas. > > Dennis > > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and delete > this e-mail from your system. E-mail transmission cannot be guaranteed to be > secure or error-free as information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. The sender > therefore does not accept liability for any errors or omissions in the > contents of this message, which arise as a result of e-mail transmission. If > verification is required please request a hard-copy version. > Please consider the environment before printing this email message > _______________________________________________ > 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
