Thank you very much for your response! I appreciate you input. > Incremental BLOB I/O handles depend on an internal statement.
Sorry, which statement is involved? int sqlite3_blob_open( sqlite3*, const char *zDb, const char *zTable, const char *zColumn, sqlite3_int64 iRow, int flags, sqlite3_blob **ppBlob );does not have a statement. To get 'ppBlob' we have to specify only iRow. > I'd turn on tracing so that you have an exact record of all the > statements that are executed. I do not do any DROPS, CREATS nothing. My table ‘A’ has a BLOB. What I do is only 1 UPDATE in the table ‘B’. I verified using sqlite3_total_changes(sqlite3*) – that only 1 changed happened – change to the row in the table ‘B’ . Yet, to my surprise the handle to the BLOB in the table ‘A’ got invalidated! I do not do any DROPS, CREATS nothing special at all! My table ‘A’ has a BLOB. What I do is 1 UPDATE in the table ‘B’. I verified using sqlite3_total_changes(sqlite3*) – that only 1 changed happened – change to the row in the table ‘B’ . Yet, to my surprise the handle to the BLOB in the table ‘A’ got invalidated! (All what I do in my code is as follows: In a loop, I find iRow for my blob in the table ‘A’, open blob in the iRow. Than I update table ‘B’ with some information from table ‘A’. Than I blob_write to the blob in the table A. This write fails frequently with code SQLITE_ABORT. I do not see any reason why it fails!) Thank you again for your comments. Best Regards, Samuel ________________________________ From: Jay A. Kreibich <[email protected]> To: General Discussion of SQLite Database <[email protected]> Sent: Tue, January 19, 2010 11:00:54 AM Subject: Re: [sqlite] Incremental i/o - Is anyone using ???sqlite3_blob_write???? On Tue, Jan 19, 2010 at 07:14:11AM -0800, a1rex scratched on the wall: > So, I coded accordingly. I thought that I could keep the same handle to the > blob forever as long > as I do not touch the row where my blob is located. At least that is my > understanding of the documentation. > > Soon, I discovered that after some updates to other table my > blob handle is no longer valid. The > problem was not consistent; some updates would invalidate the handle some > would > not. Incremental BLOB I/O handles depend on an internal statement. As I understand it, any operation that invalidates statements will also invalidate all the current BLOB handles. For example, I'm fairly sure changing the schema (any CREATE..., DROP..., etc.) will invalidate all BLOB I/O handles. I haven't verified this, but my (small) understanding of the code makes me believe this is true. As you're aware, there are other reasons a handle can become invalid. I'd turn on tracing so that you have an exact record of all the statements that are executed. When you hit a handle error, start looking through the trace log to see what might be causing it. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Our opponent is an alien starship packed with atomic bombs. We have a protractor." "I'll go home and see if I can scrounge up a ruler and a piece of string." --from Anathem by Neal Stephenson _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users __________________________________________________________________ Ask a question on any topic and get answers from real people. Go to Yahoo! Answers and share what you know at http://ca.answers.yahoo.com _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
