[EMAIL PROTECTED] wrote:
The rowid does *not* wrap if you specify AUTOINCREMENT. Once
the maximum rowid is used, all subsequent insert attempts return
SQLITE_FULL. The regression test suite contains a test for this.
Different rules apply if you do not use AUTOINCREMENT.
There is a #define that may interest the original poster.
If you compile with -DSQLITE_32BIT_ROWID=1, then rowids are
limited to 32 bits. This feature is not particularly well
tested (actually, I'm not sure it is tested at all) but it
might work. It is worth a try, I suppose.
Doesn't this mean that SQLite only supports 2^63 rows with autoincrement?
If I create a table with a with an autoincrement rowid, and then insert
a NULL id it assigns a rowid of 1. And if I try to initialize the rowid
to a large negative number (I used 2^63 +1 to avoid the largest negative
value) in order to use the other 2^63 rowids it lets me insert that one
row, but then automatically assigns the next row an id of 1.
sqlite> create table t2(i integer primary key autoincrement, d);
sqlite> insert into t2 values((1<<63) + 1, 1);
sqlite> insert into t2 values(NULL, 2);
sqlite> select * from t2;
-9223372036854775807|1
1|2
sqlite> insert into t2 values((1<<63) -1, 3);
sqlite> select * from t2;
-9223372036854775807|1
1|2
9223372036854775807|3
sqlite> insert into t2 values(NULL, 4);
SQL error: database or disk is full
sqlite>
It won't autoincrement through the negative half of the address space.
I don't think this is a real problem because of the immense size of the
address space, but someone might.
Also, does it behave the same with 32 bit values (i.e. only on half the
space or 2^31 rows are usable)? This might be more of a practical
problem for someone, but they could always switch to 64 (or 63) values
if it was.
Dennis Cote
