On Jun 18, 2009, at 11:01 AM, galea...@korg.it wrote:
> 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?
d...@sqlite.org
>
> 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
D. Richard Hipp
d...@hwaci.com
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
