It will be if you have specified autoincrement. Otherwise it will re-use the ids from deleted records.
You haven't said why you want the id. It is a bit unusual to need it (in my experience).
It will be if you have specified autoincrement. Otherwise it will re-use the ids from deleted records.
You haven't said why you want the id. It is a bit unusual to need it (in my experience).
I would agree with you yesterday; today I tried and it worked without reuse.
I created the table with the primary key without the AUTOINCREMENT, I had 12 records with ID 1 to 12, I deleted the one with ID 4 from the CLI. Then with the browser I did insert and the new record has -with surprise- the ID 13 and not ID 4 as I was expecting.
I don't have an explanation: I was waiting for a different result.
I use the ID to read the new inserted data, in another "widget" I show the new data.
There may be some algorithm involved that does garbage collection of IDs. I suspect that if you keep adding and removing records that eventually it will start reusing then.
Perhaps you could just feed it direct to the display from before it is given to the database.
Another question. Is the recipe name unique? If so then you could make that the primary key and then you just need the name to retrieve it
I thought too to a cache-like issue, so I added the AUTOINCREMENT; I don't care about the fact it uses more CPU as it is used very very seldom.
BEGIN TRANSACTION;
DROP TABLE IF EXISTS recipe;
CREATE TABLE IF NOT EXISTS recipe (
ID INTEGER PRIMARY KEY AUTOINCREMENT,
rname VARCHAR ( 255 ),
heat_6_7 INTEGER,
heat_11_12 INTEGER,
temp INTEGER,
hyst INTEGER,
purge_delay INTEGER,
spray_time INTEGER,
idle_time INTEGER,
n_cycle INTEGER
);
COMMIT;
I think I thought to a solution: look my other 3D
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.