There is insufficient information in the original request to make any sort of meaningful comment of any sort. No information as to the "content" of the so-called magical primary key is provided. Secondly, the following declaration provides for automatically incrementing unique pseudokeys (rowid) per table row: ``` create table t ( id integer primary key, ... other columns ... ); ``` If a record is inserted and the id is NULL, then it will be assigned a value 1 greater than all the id's currently in the table, unless the table is empty, in which case the value 1 will be used, and unless it overflows a 64-bit signed integer in which case an unused value will be chosen at random, and it no value can be found then "out of space" will be returned. Using this declaration instead: ``` create table t ( id integer primary key autoincrement, ... other columns ... ); ``` is exactly and precisely the same thing EXCEPT that extra CPU and I/O are expended to change the "currently" into "ever" and so that an 64-bit integer overflow results in "out of space" rather than re-using a free row number. There is almost ZERO likelihood that using "autoincrement" is needed other than for its "feel good" effects. There are **extremely** rare cases where it is needed but that is the very rare exception rather than the rule. Note that for a ROWID table the only actual primary key is the INTEGER PRIMARY KEY or the rowid, whether explicitly stated on not. A declaration of a PRIMARY KEY (that is not an INTEGER PRIMARY KEY) is merely an alternate way of spelling UNIQUE which is merely an alternate way of declaring a UNIQUE INDEX. There is no way to declare an "arbitrary" column (that is not the INTEGER PRIMARY KEY) to contain incrementing values. Only the rowid (integer primary key) is assigned automatically. You could, however, create triggers to "emulate" incrementing values in any column.