I have table in MS Access that has an AutoNumber type in field ID
After inserting some rows, the ID has become 200
Then, I have deleted the records in the table. However, when I tried to insert a new row, I see that the ID starts with 201
How can I force the ID to restart with 1, without having to drop the table and make new a new one?
In Access 2010 or newer, go to Database Tools and click Compact and Repair Database, and it will automatically reset the ID.
You can use:
CurrentDb.Execute "ALTER TABLE yourTable ALTER COLUMN myID COUNTER(1,1)"
I hope you have no relationships that use this table, I hope it is empty, and I hope you understand that all you can (mostly) rely on an autonumber to be is unique. You can get gaps, jumps, very large or even negative numbers, depending on the circumstances. If your autonumber means something, you have a major problem waiting to happen.
In addition to all the concerns expressed about why you give a rat's ass what the ID value is (all are correct that you shouldn't), let me add this to the mix:
If you've deleted all the records from the table, compacting the database will reset the seed value back to its original value.
For a table where there are still records, and you've inserted a value into the Autonumber field that is lower than the highest value, you have to use #Remou's method to reset the seed value. This also applies if you want to reset to the Max+1 in a table where records have been deleted, e.g., 300 records, last ID of 300, delete 201-300, compact won't reset the counter (you have to use #Remou's method -- this was not the case in earlier versions of Jet, and, indeed, in early versions of Jet 4, the first Jet version that allowed manipulating the seed value programatically).
I am going to Necro this topic.
Starting around ms-access-2016, you can execute Data Definition Queries (DDQ) through Macro's
Data Definition Query
ALTER TABLE <Table> ALTER COLUMN <ID_Field> COUNTER(1,1);
Save the DDQ, with your values
Create a Macro with the appropriate logic either before this or after.
To execute this DDQ:
Add an Open Query action
Define the name of the DDQ in the Query Name field; View and Data Mode settings are not relevant and can leave the default values
WARNINGS!!!!
This will reset the AutoNumber Counter to 1
Any Referential Integrity will be summarily destroyed
Advice
Use this for Staging tables
these are tables that are never intended to persist the data they temporarily contain.
The data contained is only there until additional cleaning actions have been performed and stored in the appropriate table(s).
Once cleaning operations have been performed and the data is no longer needed, these tables are summarily purged of any data contained.
Import Tables
These are very similar to Staging Tables but tend to only have two columns: ID and RowValue
Since these are typically used to import RAW data from a general file format (TXT, RTF, CSV, XML, etc.), the data contained does not persist past the processing lifecycle
I think the only ways to do this is outlined in this article.
The article explains several methods. Here is one example:
To do this in Microsoft Office Access 2007, follow these steps:
Delete the AutoNumber field from the main table.
Make note of the AutoNumber field name.
Click the Create tab, and then click Query Design in the Other group.
In the Show Table dialog box, select the main table. Click Add, and then click Close.
Double-click the required fields in the table view of the main table to select the fields.
Select the required Sort order.
On the Design tab, click Make Table in the Query Type group. Type the new table name in the Table Name box, and then click OK.
On the Design tab, click Run in the Results group.
The following message appears:
You are about to paste # row(s) into a new table.
Click Yes to insert the rows.
Close the query.
Right-click the new table, and then click Design View.
In the Design view for the table, add an AutoNumber field that has the same field name that you deleted in step 1. Add this AutoNumber
field to the new table, and then save the table.
Close the Design view window.
Rename the main table name. Rename the new table name to the main table name.
I always use below approach. I've created one table in database as Table1 with only one column i.e. Row_Id Number (Long Integer) and its value is 0
INSERT INTO <TABLE_NAME_TO_RESET>
SELECT Row_Id AS <COLUMN_NAME_TO_RESET>
FROM Table1;
This will insert one row with 0 value in AutoNumber column, later delete that row.
Related
In MS Access 2016 I have a table named Master that periodically needs to gets updated with ‘updated’ data from a table named NewData. Each table has the same fields, except Master has one additional field named OTHER_SOURCES (explained further down). They each have an indexed unique id field named EVENT_ID. I’ve built an update query where the tables are joined one-to-one on the EVENT_ID field. In this query I have the fields in Master getting updated to the new values from the same fields in NewData if the TIMESTAMP field value is different. If the TIMESTAMP values haven’t changed, then those records do not get updated. This part is pretty straightforward and works fine.
However, I have end users that may make occasional changes to the values in the SIZE field of Master that need to be preserved and not overwritten with updated values from NEW_DATA. When a user makes a change in SIZE field, he documents the change with information obtained from other sources, which is stored in the extra field I mentioned earlier: OTHER_SOURCES. Here’s what I need to do, and I just can’t figure it out. Whenever a user has made a change to the SIZE field for a record, I need the update query to not override that value in the SIZE field, but still update the values in all the other fields (again, assuming the TIMESTAMP values are different between the two tables). It seems I need to use an IIF statement, but I’m thinking it needs to be done in VBA where I’m a bit of a hack. See screenshots. I greatly appreciate any help you can offer.
enter image description here
enter image description here
You can still proceed with the update, but update it to the same value as its previous value:
SET SIZE= IIF(nz(OTHER_SOURCES,'')<>'', MASTER.Size, NEW_DATA.Size)
This assumes that anything present in the MASTER.OTHER_SOURCES column indicates that the user has changed MASTER.Size. Note that MASTER.Size will never be updated from NEW_DATA.Size until someone (end user) removes MASTER.OTHER_SOURCES.
I have an old dbase-database (made with a program programmed with clipper 5.2) which consists of multiple tables (files). The tables are linked with some sort of recordnumber, but in the source table, no recordnumber-field is found. I want to convert this database to Access and re-establish the links. I've read something about a dbf recordpointer (?) but i don't know how to extract it from the DBF.
Well, if recno() or some such is being used, then it suggests that the table starts at one.
Remember, you can’t update a PK autonumber in Access, BUT YOU CAN RUN append queries against such tables!!!
So link to a dBase table. When you view this table in Access does it show that incrementing column?
It should and does for me.
The above detail has not been made clear by you.
So let’s assume you see this column that increments and is NOT marked as a PK?
That is just fine (and is expected). As LONG as you see the incrementing number in that linked table then you are just fine.
This process of importing then becomes rather fast and easy.
On the create ribbon tab, just choose query design.
Drop in that linked table.
From ribbon choose make table. Enter your new local table name.
Drag the * from the table into the into the query grid (first column of grid).
You have this:
Now run the above query query (hit the run button in ribbon).
Exit (toss that query out – no need to save).
The result will be a new local table, with that number column.
Now, empty data from that local table.
(Ctrl-g to debug window)
Currentdb.execute "delete * from NewLocalTable"
Now do a compact + repair (this re-sets any autonumber columns in empty tables – might not be required – but just do it anyway). And it reclaims the empty space for that table we just emptied out.
Ok, now open that new local table in design mode. Select that first number id column, and delete it. (click on that row - likely first row - hit del key).
Now, click on first row to select the column that is first. Hit insert key to push it all down, and enter the name of the numbering column you JUST deleted. Tab key, autonumber, and then from ribbon whack the PK button (primary key button).
Close table designer. Save the design changes.
We now have an empty table with a PK autonumber column as the SAME name as what we had before.
Now, create new query, droop in linked table.
From ribbon choose append query, and enter name of new local empty table.
Drag the * into the query grid.
Run it.
We now have a local table, with PK autonumber, and the columns will match up to the linked table.
For a 10 second test?
Ctrl-g (jump to debug window).
Type in:
? dcount("*","linkeddBaseTabble name")
? dcount("*","NewlocalTable name")
The record counts should be the same.
At this point you have a local table with same columns + the PK ID autonumber column.
You can repeat the above over and over. It goes fast. 20-30 tables will not take long.
The result is now local tables, and each table will have an autonumber PK column with the same column name.
I would think the column as a linked table is “ID”, but it might be RECNO. (So use that for the local PK column names).
So you:
Link to dbase table.
Query builder – make table.
Ctrl-g to empty local table:
Currentdb.execute "delete * from local table name"
Open local table in desing - delete number column, add it back as PK autonumber.
Query builder, drop in linked table. From ribbon select append query, enter name of local table.
Drag “*” to query grid – run it.
You now have a local table, with PK autonumber same as linked table.
Move on to next table to import (add an autonumber to each table you import with above few steps.
You could just import the tables in Access...and work your way using them as blueprint.
Just ensure that the "table relations" are correct... i know that there isn't one but take the "logical" path...if you a table with a fieldName "FaxBookID" and you have a table "FaxBook" ...you know they are related
I need a table where all deleted items from my main table go. I found the easiest way to do this is to copy my main table, paste the table and change the name. In my main table I went to the design tab, Create Data Macros, after delete. In the set field I put the name of the field, and for the value I put [Old].[ID] etc. My problem is this works great until I try to add in my "comments field" to the list. My comments field data type is "Long Text".
Somethings I have tried: deleting all calculated fields and adding them back in as short text (worked for some fields), Deleted all default values, deleted all validation rules.
Expected result would be for my deleted record from my main table to show up into the deleted records table. I receive no error message when deleting a record. It simply doesn't add to the to the deleted table. Thanks for looking.
Why copy tables? Create a yes/no field On your table called "Deleted." Then you can run a query for or against that field depending on if you want to see the deleted data or not. Add the field to existing queries that shouldn't show these, and set its criteria to false.
Access 2013
I have a simple lookup table that twice in the last month a record (different record on each occasion) has disappeared.
Since the auto id of the table is used as the foreign key I am forced to drop the table and recreate it.
I don't provide any delete functionality at all to users in the Access DB and especially not to the lookup table.
I have done a global search for all references to the table in my VBA code and found it was used several times but only in select statements.
At the moment I suspect a user is fiddling with something they don't fully understand and they are inadvertently deleting the record.
What else can I do determine the cause of this problem?
Can I make the lookup table read only?
Look at the relationships window. Look at the linked tables in question and see if there is a 'Cascade Deletes' checked. If so, deleting one record will delete related records.
It turned out to be a second lookup table that had a temporary relationship defined in the query that was not required. i.e: no columns were based upon this unnecessary table. This unnecessary lookup table was simply being used as a row source for a combobox on the form.
I discovered this after I noticed the form data type was set to Dynaset (Inconsistent Updates). Why? When I tested the form with normal Dynaset the form refused to perform any updates!
When I removed the unnecessary lookup table from the query I was able to set the data type back to Dynaset with updates continuing to work and deletions no longer cascading through to my first and required lookup table.
In addition the unnecessary lookup table was actually a query that was referencing a table in another database.
I have two tables named [Insert_Record] and [Delete_Record] in MS Access. Both tables have the same fields but one table has records whereas another table has no record.
Question: I want, whenever I delete any record from the table [Insert_Record] that entire record should automatically insert into another table, i.e: [Delete Record].
How can I accomplish this?
Access 2010 introduced event-driven Data Macros that are similar to triggers. The process described in the question can easily be done with an After Delete data macro on the [Insert_Record] table:
As I understand it, Access doesn't have triggers.
The best you can probably do is put this sort of logic into the forms that edit the table. In other words, handle the deleted event at the form level and put your insert logic there.
If you want triggers, you'll want to use a proper RDMS that supports them (MySQL, MS SQL, Oracle, many others).
EDIT: Another way to do this (which may or may not work for you) would be to add a boolean column 'IsDeleted'. That way, you can just logically delete a record instead of moving it to another table. The downside of this approach is the deleted records stay in the main table which could cause performance woes if there are lots of deletes.
Create an append query, to add records into the second table, that is executed in the On Delete Confirm event of the form you are using to delete the record from the first table.
I imagine this 'Delete' is button driven...
So program the button to first Insert the record into one table before deleting it.
Just add the VBA for the insert above the delete.
Another method which nullifies your need for another table entirely is just one column that is a boolean... Active Yes/No (Default to yes.)
If Active then it is not actually deleted when they hit delete, just set the flag to False then nothing is actually deleted, no SQL code is required and there is no risk, you can even have a column with the user who updated it print in another column
Me.Active = False
Me.UserName = 'CurrentUser Location here
Me.RecordSet.Requery
Then there is no risk of actually losing anything is there and you have a record of who flagged it last.
In the continuous form just add the Where flag Active = True then no false flags will show and it looks to the user base as if it was deleted.