SQLite Forum

Best way to handle unique column needs
Login
I respond, not to argue the point [a], but to clarify for the OP why I recommended using autoincrement for what I perceived as his problem.

[a. I might quibble with "99.9999999999999% of the time ..." because I am sure that my own useful usages alone would invalidate that figure. ]

My assumptions regarding the OP's problem are: (1) That his "old unique key fields" were serving as the primary key for their respective tables; (2) That he does not much care what the key values are after the transition to SQLite; (3) That after the transition the DB will still be live, with new rows being added sometimes which will need new (primary) key values [b]; and (4) That there are link relations among the old primary key values and their use as foreign keys in the rest of the old data. [c]

[b. I inferred this assumption from the OP's statement, "I need it to auto fill itself with a value", which nearly encapsulates the most common use case for the autoincrement feature. ]

[c. That last PK/FK assumption was unclear, so I prompted for its clarification. ]

It was only assumption 3, founded on the OP's "need it to auto fill" claim, that led to my recommending use of autoincrement.  If, in fact, there is another good source of unique primary key values in the incoming new data, (or there is to be no new data), where the primary key values will always be inserted, (or never be needed), then the "AUTOINCREMENT" is just excess baggage, a waste of typing, storage and CPU cycles. However, if the OP would have to do any work or have the DBMS do any work to derive new primary key values, then AUTOINCREMENT is an efficient way to get that done. (And, the OP's use case may fall among the 0.0000000000001% or maybe higher fraction of cases where the feature is well used.)