SQLite Forum

Best way to handle unique column needs
Responding to your issues and questions in order:

When I wrote 'mumbleId' in the position of a column name, and "with mumbleId chosen more intelligently", I could have elaborated that you might wish to use a column name for your primary key that is more meaningful. Some people just use 'id' or the like, but joins can be more conveniently written when foreign keys and primary keys have the same name. Unless you have a table named 'Mumble', 'mumbleId' is probably a poor choice. Regard it as a stand-in for better choices.

As Keith said, (and as I now agree, having relearned something about SQLite), there is likely no need to use AUTOINCREMENT, and certainly no such need evident in what you have posted so far.  See [ROWIDs and the INTEGER PRIMARY KEY](https://sqlite.org/lang_createtable.html#rowid) and [SQLite Autoincrement](https://sqlite.org/autoinc.html) in particular. So just write something like (but differing from) "CREATE TABLE Something( somethingId INTEGER PRIMARY KEY, ...)". You can then insert your old data, taking care that the old unique integer key values are inserted as the (perhaps) newly named primary key column values, and SQLite will take care of generating more unique key values as you subsequently insert new data rows.

You keep writing things such as "but I just get back zeros in that column when I fetch after an insert" and "the primary key that is allready there not returning a value".  Neither I nor anybody else who might help you with those problems has enough, from such summary or conclusory assertions, to divine what you are doing differently from what has a chance of working. So, I repeat my earlier advice: It would help to show DDL and queries, together with results that seem awry. This means showing your DDL and queries verbatim, rather than your opinion as to what effects they might or should have, and what actual results you observed rather than summaries that are likely to obscure what happened.

SQLite has a nice little shell with which you can demonstrate, with just a few lines of SQL, what you did and what happened. That, together with what you expected, will suffice to permit other forum participants to help you, by either adjusting your expectation(s) or informing you what to do differently.