Question

I created a C++ application that updates a SQLite database. The application reads a row, does an action with the values in the row, then updates the “modified” column with the current time. I believe that I am only using SELECT, INSERT, CREATE commands.

The application runs correctly for the first few days before problems start to occur. When I checked the database settings with sqlite-administrator I found that there was a table that has a row with a duplicate key values.

I created the table with this command

CREATE TABLE 'XXXX_tasks' ( 'id' INTEGER PRIMARY KEY ,  'data_length' INTEGER,  'data_offset' INTEGER,  'data_table' TEXT,  'device_id' INTEGER,  'modified' INTEGER,  'name' TEXT,  'object_id' INTEGER,  'object_type' TEXT,  'object_units' INTEGER,  'property' INTEGER,  'scan' INTEGER,  'type' TEXT )

The data in the table looks like this (reduced for readability)

ID | Name  | Object ID 
 5 | AV_33 | 33         <===  
 2 | AV_34 | 34 
 3 | AV_35 | 35 
 4 | AV_36 | 36 
 5 | AV_33 | 33         <=== 

It appears that the there are two rows with a duplicate KEY field. At first I thought that it was a corrupted database file, A fluke. I deleted the database file and restarted the application. After a week the same problem occurred. Its repeatable.

You can download/view the database file yourself here http://www.abluestar.com/files/uploads/database_jan312012.db

My question is:

I can’t think of any reason that you could create a create or update a row to have a duplicate primary key value. Any ideas how this could have happen?

Answer 1

sqlite> select distinct id from BACnetIP_tasks order by id;
5
2
3
4
5

The two 5s are distinct, and one 5 is less than 2. Sounds like a corrupt file.

sqlite> pragma integrity_check;
*** in database main ***
On tree page 4 cell 1: Rowid 2 out of order (previous was 5)
Fragmentation of 15 bytes reported as 12 on page 4

Yep. So, the good news is that SQLite sees essentially the same problem you do. Row 2 is, indeed, out of order, since the previous row was 5. Corrupt file.

Any ideas how this could have happen?

Not off the top of my head, but the odds are good that the problem is in your code. Almost every time something like this has happened to me, it’s been my problem, not the database’s. (Although I do recall discovering a couple of bugs in Access 2000 a long time ago.)

SQLite3 supports RENAME TABLE and ADD COLUMN, but it doesn’t support any other parts of the ALTER TABLE syntax. So I don’t think what you’re seeing could be caused by ALTER TABLE statements. Besides, SQL statements are supposed to fail rather than result in an inconsistent database. (That would seem to rule out triggers, too, at least under normal circumstances.)