A client of mine accidentally deleted about 500 records from an access table that has a primary ID field which was created as "autonumber". By turning off the autonumber column (changing back to a integer), I was able to restore the missing 500 records from a backup, but now of course the autonumber cannot be turned back on...
What are some possible solutions? The ID field is used as a link to other tables, so I can't just renumber everything without also renumbering all of the tables that reference this number (a pain in the neck, but possible).
Is there any "trick" to turning autonumber back on, using the max(id) as the starting point if data already exists in the table?
Make newTable with ID field as AutoNumber (all fields must be same as in original table - except ID). Copy all data from originalTable to newTable:
INSERT INTO newTable SELECT * FROM originalTable
Once data is filled, delete originalTable and rename newTable to originalTable.
This way all "holes" in auto-numbering are preserved and newTable has Auto-Numbering turned on.
P.S. Always try to add foreign keys to your IDs. In that case, even if some data is deleted, you will at least have consistent state.
The ideal solution, although it's now too late, wouuld've been to restore the missing 500 records into a working table. Then do an Append query into the main table. This would've included the Autonumber field.
If I could add to the answers given.
A little known fact about Access autonumber fields is that the counter on them is reset when you compact and repair the database.
I am also pretty sure that if you do an insert it WILL use the numeric that is supplied rather than the next number in the autonumber counter as long as it is > (greater than) the internal counter kept by the auto-number field (does that make sense at all?)
In other words you CAN do something like this in an brand new access table where the counter should be set to 1...
INSERT INTO myTable (myAutoNumber,myOtherField) VALUES (10000,'other data')
The other solutions mentioned here are better because they would do a better job of guaranteering the result so I mention it almost for academic reasons.
Seth
Agree, but may want to add an ORDER BY to ensure that the AutoNumber is in the correct order. Otherwise your other tables will have the wrong ID association.
INSERT INTO newTable SELECT * FROM originalTable ORDER BY ID
You will also have to explicitly name the fields instead of using *
You make a new field and make it auto-number and then delete id field and rename new field to id
Related
I would like to add an AutoNumber field in an Access table but ID is already type Autonumber and is used for the index in the table. You can't have more than one Autonumber field in a table apparently.
The use case is: Existing database of Clients with existing Client_Number record. I want the ability to enter an 'old' client from this database and set their Client_Number to what it is in the existing database (eg Access Autonumbers it as 405 but I'll overtype that with 3245). But I also want to add NEW clients and have the system assign a number automatically (beginning at 4001) if possible.
Can anyone help me or is it impossible? I have googled for a solution but nothing is forthcoming.
you'll have to remove the auto-increment index from the original column and add it to a new one column (it might require to temporarily remove table/field dependencies, especially when they are cascaded updates/deletes), then you can key in the new values without any risk to loose the index. once the new index has been built up, reset it's auto-increment value to 4000 - and the next new record will get 4001. as long as one keeps the old index, one still can use it to update dependent tables with the new IDs - and then add the dependencies towards the recently introduced column - and remove the old index column.
When I insert data into a brand new table, it will assign a new id via AUTO_INCREMENT. So the first time I perform an insert I get an id of 1. However, if I delete the row and insert new data, the table acts as if there is still a preceding row (the new row will have an id of 2). This behavior concerns me because I feel like the data is still persisting somewhere. Any ideas of what it could be?
Your data is not persisting. MySql maintains a separate table about your table containing, among other things, the next auto-increment value for your table. You can reset this with:
ALTER TABLE tablename AUTO_INCREMENT = 1
However, be aware that if you are resetting to a value below another valid value in the table, you're asking for trouble.
you should simply use.
truncate table tablename;
I have a table1 with an id field, type AutoIncrement. I need to copy the entire record from table1 into table2 if there is no record with the same id in table2. Then I delete the record from table1.
I need to know that if table1 gets new records, the id field will never be a number that was ever used before. Does this happen automatically, or do I need to do something to ensure this?
I tried deleting some records and adding new ones, and it really didn't use the same id, but I'm not sure that this is what always happens.
It is possible to duplicate numbers in autoincremet field quite easy, but normally applications don't work this way.
Access remembers last inserted value in autoincrement field and uses it for calculating next value. You cannot insert particular value into autoincrement field using table designer or recordset in VBA, but it's possible if you use INSERT SQL statement. So, if autoincrement field has no unique index, you can insert any value. Also if you insert value less than maximum existing number, Access will generate duplicates automatically.
So I would not recommend rely on unique autoincrement numbers without unique index.
INSERT SQL can be used for resetting numeration without dropping field/table, just run query like this in query builder or using VBA:
INSERT INTO Table1 ( id ) SELECT 1;
This is table with autoincrement field ID I just created:
it is really so, Auto-increment fields in MS Access are always incremental, even if records are deleted, database compacted, etc.
The proposed number can be reset deleting the auto-increment field, perform the copy of the table and then adding the auto-increment field again.
Auto increment never uses the same # even though it's deleted from the table.
It requires complete reset so that it will start from the base and create new #.
I have a table in MySQL using InnoDB and a column is there with the name "id".
So my problem is that whenever I delete the last row from the table and then insert a new value, the new value gets inserted after the deleted id.
I mean suppose my id is 32, and I want to delete it and then if I insert a new row after delete, then the column id auto-increments to 33. So the serial format is broken ie,id =30,31,33 and no 32.
So please help me out to assign the id 32 instead of 33 when ever I insert after deleting the last column.
Short answer: No.
Why?
It's unnecessary work. It doesn't matter, if there are gaps in the serial number.
If you don't want that, don't use auto_increment.
Don't worry, you won't run out of numbers if your column is of type int or even bigint, I promise.
There are reasons why MySQL doesn't automatically decrease the autoincrement value when you delete a row. Those reasons are
danger of broken data integrity (imagine multiple users perform deletes or inserts...doubled entries may occur or worse)
errors may occur when you use master slave replication or transactions
and so on ...
I highly recommend you don't waste time on this! It's really, really error prone.
You have two major misunderstandings about how a relational database works:
there is no such thing as the "last row" in a relational database.
The ID (assuming that is your primary key) has no meaning whatsoever. It doesn't matter if the new row is assigned the 33, 35354 or 236532652632. It's just a value to uniquely identify that row.
Do not rely on consecutive values in your primary key column.
And do not try the max(id)+1 approach. It will simply not work in a system with more than one transaction.
You should stop fighting this, even using SELECT max(id) will not fix this properly when using transactional database engine like Innodb.
Why you might ask? Imagine that you have 2 transactions, A and B, that started almost at the same time, both doing INSERT. First transaction A needs new row id, and it will use it from invisible sequence associated with this table (known as AUTOINCREMENT value), say 21. Another transaction B will use another successive value (say 22) - so far so good.
But, what if transaction A rolls back? Value 21 cannot be reused, and 22 is already committed. And what if there were 10 such transactions?
And max(id) can assign the same value to both A and B, so this is not valid as well.
I suppose you mean "Whenever I delete the last row from the table", isn't it?
Anyway this is how autoincrement works. It's made to keep correct data relations. If in another table you use an id of a record that has been deleted it's more correct to get an error instead of get another record when querying that id.
Anyway here you can see how to get the first free id in a field.
I have an invoices table which stores a single record for each invoice, with the id column (int AUTO_INCREMENT) being the primary key, but also the invoice reference number.
Now, unfortunately I've had to manual migrate some invoices generated on an old system which have a five digit id, instead of a four digit one which the current system uses.
However, even when I reset the AUTO_INCREMENT through PhpMyAdmin (Table Operations) back to the next four digit id, it still inserts a five digit one being the higher id currently in the table plus one.
From searching around, it would seem that I actually need to change the insert_id as well as the AUTO_INCREMENT ? I've tried to execute ALTER TABLE invoices SET insert_id=8125 as well as ALTER TABLE invoices insert_id=8125 but neither of these commands seem to be valid.
Can anyone explain the correct way that I can reset the AUTO_INCREMENT so that it will insert records with id's 8125 onwards, and then when it gets to 10962 it will skip over the four records I've manually added and continue sequential id's from 10966 onwards. If it won't skip over 10962 - 10966 then this doesn't really matter, as the company doesn't generate that many invoices each year so this will occur in a subsequent year hence not causing a problem hopefully.
I would really appreciate any help with this sticky situation I've found myself in! Many Thanks
First thing I'll suggest is to ditch PHPMyAdmin because it's one of the worst "applications" ever made to be used to work with MySQL. Get a proper GUI. My favourite is SQLYog.
Now on to the problem. Never, ever tamper with the primary key, don't try to "reset" it as you said or to update columns that have an integer generated by the database. As for why, the topic is broad and can be discussed in another question, just never, ever touch the primary key once you've set it up.
Second thing is that someone was deleting records of invoices hence the autoincrement is now at 10k+ rather than at 8k+. It's not a bad thing, but if you need sequential values for your invoices (such as there can't be a gap between invoices 1 and 5) then use an extra field called sequence_id or invoice_ref and use triggers to calculate that number. Don't rely on auto_increment feature that it'll reuse numbers that have been lost trough DELETE operation.
Alternatively, what you can do is export the database you've been using, find the CREATE TABLE definition for the invoices table, and find the line where it says "AUTO_INCREMENT = [some number]" and delete that statement. Import into your new database and the auto_increment will continue from the latest invoice. You could do the same by using ALTER TABLE however it's safer to re-import.