Hallo Odekirk Shawn,
SQLite use up to an 64Bit signed Integer for Primary Keys, even on non
64Bit-Systems!
Integer PrimaryKeys are always autoincrementing. When you don't specify it it
uses after (2^63)-1
a random free positiv value. When you write autoincrement for your create table
it never reuse
deleted positiv values and you get an SQLITE_FULL error, thats all.
And please don't forget the not null for your primary key. Without this you get
a little bit
different behavior.
Greats,
Brickl
--- "Odekirk, Shawn" <[EMAIL PROTECTED]> schrieb:
> I am evaluating SQLite for a project I am working on.
>
> I have a question about the behavior of the INTEGER PRIMARY KEY auto
> increment feature.
>
> My platform uses 32 bit integers, so the valid values for an unsigned
> integer are 0 - 4294967296 and the valid values for a signed integer are
> -2147483648 - 2147483647.
>
> Since the INTEGER PRIMARY KEY data type is a signed integer, the maximum
> positive value is 2147483648. If my table already has a row with the
> maximum positive value in the primary key field, and I insert a row
> using NULL as the value of the primary key field, the row is inserted
> and the primary key is assigned the value of -2147483648. That makes
> sense to me and I have no problem with that. The problem is that the
> next row I insert generates the error "SQL error: PRIMARY KEY must be
> unique". I suspect that this is because SQLite tries to use the next
> largest positive value when it increments the primary key field.
>
> Is there an easy way to cause the INTEGER PRIMARY KEY column to use an
> unsigned integer instead, or to roll over to 0 instead of the most
> negative value for the data type?
>
> I suspect that in practice I will not run into this issue. However, I
> would feel better knowing that there is no chance that I will encounter
> this problem.
>
>
>
> Thanks,
>
> Shawn
>
>
>
>
__
Yahoo! Clever: Sie haben Fragen? Yahoo! Nutzer antworten Ihnen.
www.yahoo.de/clever
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
