I run "PRAGMA integrity_check" using version 3.6.14 at the end of the
code and it executed a query with only one row "ok", so where do I
have to send the databbase?
Thanks
Citando "D. Richard Hipp" <d...@hwaci.com>:
>
> On Jun 18, 2009, at 9:04 AM, galea...@korg.it wrote:
>
>> I updated sqlite version from 3.6.14 to 15, now when I try to run a
>> C++ code to fill the database I have SQLITE_CORRUPT error.
>
> New logic was added to version 3.6.15 to detect database corruption
> sooner.
>
> What happens when you run "PRAGMA integrity_check" using version
> 3.6.14? Do you see the problem then too? If so, that means your
> database is corrupt and it was simply going undetected before. If
> not, then please email you database and I will have a look.
>
>
>> This error
>> happens in the accessPayload method (btree.c) in the condition
>> if( rc==SQLITE_OK && amt>0 ){
>> return SQLITE_CORRUPT_BKPT;
>> }
>> where rc is SQLITE_OK but amt = 12070.
>> It follows a part of call stack:
>> int sqlite3BtreeKey(BtCursor *pCur, u32 offset, u32 amt, void *pBuf){
>> ..........
>> rc = accessPayload(pCur, offset, amt, (unsigned char*)pBuf, 0, 0);
>> }
>>
>> static int saveCursorPosition(BtCursor *pCur){
>> ...
>> if( pKey ){
>> rc = sqlite3BtreeKey(pCur, 0, (int)pCur->nKey, pKey);
>>
>> static int saveAllCursors(BtShared *pBt, Pgno iRoot, BtCursor
>> *pExcept){
>> BtCursor *p;
>> assert( sqlite3_mutex_held(pBt->mutex) );
>> assert( pExcept==0 || pExcept->pBt==pBt );
>> for(p=pBt->pCursor; p; p=p->pNext){
>> if( p!=pExcept && (0==iRoot || p->pgnoRoot==iRoot) &&
>> p->eState==CURSOR_VALID ){
>> int rc = saveCursorPosition(p);
>> if( SQLITE_OK!=rc ){
>> return rc;
>> }
>> }
>> }
>> return SQLITE_OK;
>> }
>>
>> int sqlite3BtreeDelete(BtCursor *pCur){
>> .....
>> (rc = restoreCursorPosition(pCur))!=0 ||
>> (rc = saveAllCursors(pBt, pCur->pgnoRoot, pCur))!=0 ||
>> (rc = sqlite3PagerWrite(pPage->pDbPage))!=0
>> ){
>> return rc;
>>
>>
>> The statement is:
>> "INSERT INTO PlayList_Song(id_song, id_playlist, song_number) VALUES
>> (?, ?, ?)"
>> and the table is:
>> CREATE TABLE PlayList_Song (
>> id_song INT NOT NULL,
>> id_playlist INT NOT NULL,
>> song_number INTEGER NOT NULL,
>> PRIMARY KEY (id_playlist, song_number),
>> CONSTRAINT fk_PlayList_Song1 FOREIGN KEY (id_song)
>> REFERENCES Song (id)
>> ON DELETE CASCADE
>> ON UPDATE CASCADE,
>> CONSTRAINT fk_PlayList_Song2 FOREIGN KEY (id_playlist)
>> REFERENCES PlayList (id)
>> ON DELETE CASCADE
>> ON UPDATE CASCADE);
>>
>> CREATE INDEX PlayList_Song_song_number_idx ON
>> PlayList_Song(song_number);
>>
>> Have you got any ideas about this problem? Is it a bug of new version?
>> _______________________________________________
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> _______________________________________________
> 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
