The number isn't getting committed to a table. Only to a view based on the table. I think the author did it this way so as to not mess with the program which owns the database the view is being created from. I'm not sure where in his code the integer becomes important. I could likely figure it out, but damn if I'm not looking to change how the thing functions at that
I could probably add a column to the table with a UID of some sort, but I don't know enough to know if this might effect anything else in the system... and I'm not sure where I would have to build such a function in to the program itself so that each new addition gets the new ID. I could probably figure it all out, but future updates and breaking etc.
The simplest thing seems to be to somehow correct the tiny bit of SQL that's attempting to give each row in the view a unique integer. I can think of a few ways to achieve a unique ID based on the data, but the requirement of it being an integer keeps pulling me short.
If the view needs an ID for some reason, does the table storing users not have its own primary key?
It doesn't. I have no idea if this is poor design or not at my knowledge level. I have some strings that are unique... but deriving an integer from one of them, and ensuring the resulting integers would be unique... ugh.
Sucking down the easy flowing milk from society's warm breasts.