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.
Related
I need to move a table from within an ms access database to a SharePoint list. The table I need to move has had old records removed that has ID's auto increment. I need the SharePoint list to start from the same auto increment number as in the table.
I have tried using the ms access export to SharePoint list functionality but when I re-import the table back into access as a linked table to a SharePoint list the ID has started back at 1 (not 81 like in the table I uploaded to SharePoint).
I need the table to upload to the SharePoint list with the auto increment ID starting at 81 as it is in the table initially.
I understand Albert's logic, but somewhat disagree. I worked with one client that had been using an original Auto-numbered field as the Customer's ID in their access database for years, so their work orders, invoices, etc..., all have the Customer's ID there. If you use the newly-created autonumber field, then all customer id's would change to new numbers. Worse yet, if you use a 2nd, non-autonumber field as Albert recommends, then anytime you add a new customer, you would need to use a sql statement (or query) to determine the last used number from this 2nd field and increment it 1 so that it is unique. Kind of a pain.
So, the workaround is still a pain, but for a solution that does what you actually asked, you can do this. Create a new list in SharePoint with an auto-numbered field. link that list in the access database. then, look at the highest ID number (eg highest customer id) from the table with your original data... because you need to create that many rows in the SharePoint list. You can either create code to loop through creating x number of records, or if you're not comfortable with that, create an excel sheet with that many rows. then, import that excel file into the linked table. next, create a delete query which deletes all records in the linked table that doesn't have the matching ID (eg customer ID) in your access table. this leaves you with a linked list with only the IDs you are using, and it's still auto-numbering so new records are automatically assigned new numbers.
Like I said, it's a bit of a work-around. But this actually does what you are asking for, instead of being forced into a different solution.
If the column in question is a autonumber column, then during a upload or migration then those autonumbers can change. Since such numbers have NO meaning, then this should not matter. If you have several related tables then you MUST ensure that your relations are setup correctly before you move the data to sharepoint (because SharePooint will re-number these values, then the child tables and FK keys ALSO will be correctly updated). However, if you don't set the relationships, then you WILL break the related data since SharePoint does and can and will re-number the PK's used.
You are limited to ONLY using autonumber PK's if you wish to keep related tables intact. You cannot control this re-numbering, but as noted the number ONE rule in databases is that such numbers do NOT matter anyway.
If you MUST and WANT to stop the re-numbering of that column, then change the data type to a long number, and NOT autonumber type. And then of course simply add another autonumber column. So to STOP or PREVENT the numbers being changed, you have to convert the column from being autonumber to a standard long number column. (edit: you ALSO thus have to ensure that the column is NOT marked as PK).
Keep in mind that any other table as part of the related data will ALSO see those standard long number columns re-numbered and changed if that column is part of a defined relationships to some PK. So Access during a up-size WILL re-number the PK (autonumber) and will ALSO automatic for you re-number the FK columns used in child tables. If you as noted do NOT want such re-numbering to occur, then the PK and FK columns can NOT be part of a defined relationship.
So dropping the autonumber column is the only way to prevent such re-numbering. Since autonumbers don't have any real meaning, then if they are changed during a up-load, then this should not matter.
I am trying to add a row in existing table I want to make it unique when I am trying to alter in phpmyadmin it says #1062 - Duplicate entry '0' for key 'mobile'
What code will help me suggest
This indicates that you have two entries which both have '0' in the mobile column. You can't force the column to be UNIQUE because there's non-unique data in their now. The solution is to resolve the conflict, but whether that's a good idea and how exactly to do so depends on your database design. The act of doing it is rather simple (just edit that row and assign a new value for 'mobile'), but depending on your design that could damage some data.
So without knowing the details, I can only caution you to not destroy any data or relations.
If you don't have a primary or unique key in that table, phpMyAdmin doesn't show the '"grid edit" feature, so if that's the case you can either write a little SQL to update the row directly, or temporarily add a new column, make it an autoincrementing primary key, do the edit through the phpMyAdmin interface, then remove the temporary autoincrement column (that's what I'd do; I just tested it and it took me about 30 seconds to add the column and key, edit a row, and delete the temporary column).
I have an access database. In this I have a table which had an auto number field that created the ids. I somehow deleted these ids in the table. Now that I have deleted these records, I need a same sequence to continue (I want the deleted ids back in the table), but I am not able to do so because the auto number feature deleted the ids forever. I tried changing the field datatype to just number and entering the ids manually, but it won't change because the database gives me a warning saying that it is related to other features and I need to delete them first, something to do with relations. Please help me figure out a way to get the old ids in the table. The database is pretty complex, it doesn't just have one table, it has a lot of forms and reports and they are all intertwined. HELP!
Access will allow you to execute an INSERT statement which adds a row with an unused autonumber value.
INSERT INTO MyTable (auto_num_field, text_field)
VALUES (27, 'foo');
However if Access objects due to a defined relationship, you need to first drop the relationship, add the data, do whatever else is needed to satisfy the relationship constraint, and finally re-create the relationship.
OTOH, if you've already changed the field's data type from autonumber to something else, and you don't have a backup copy of the table, this could be even more challenging. We'd need more information to figure out a solution.
I am considering designing a relational DB schema for a DB that never actually deletes anything (sets a deleted flag or something).
1) What metadata columns are typically used to accomodate such an architecture? Obviously a boolean flag for IsDeleted can be set. Or maybe just a timestamp in a Deleted column works better, or possibly both. I'm not sure which method will cause me more problems in the long run.
2) How are updates typically handled in such architectures? If you mark the old value as deleted and insert a new one, you will run into PK unique constraint issues (e.g. if you have PK column id, then the new row must have the same id as the one you just marked as invalid, or else all of your foreign keys in other tables for that id will be rendered useless).
If your goal is auditing, I'd create a shadow table for each table you have. Add some triggers that get fired on update and delete and insert a copy of the row into the shadow table.
Here are some additional questions that you'll also want to consider
How often do deletes occur. What's your performance budget like? This can affect your choices. The answer to your design will be different depending of if a user deleting a single row (like lets say an answer on a Q&A site vs deleting records on an hourly basis from a feed)
How are you going to expose the deleted records in your system. Is it only through administrative purposes or can any user see deleted records. This makes a difference because you'll probably need to come up with a filtering mechanism depending on the user.
How will foreign key constraints work. Can one table reference another table where there's a deleted record?
When you add or alter existing tables what happens to the deleted records?
Typically the systems that care a lot about audit use tables as Steve Prentice mentioned. It often has every field from the original table with all the constraints turned off. It often will have a action field to track updates vs deletes, and include a date/timestamp of the change along with the user.
For an example see the PostHistory Table at https://data.stackexchange.com/stackoverflow/query/new
I think what you're looking for here is typically referred to as "knowledge dating".
In this case, your primary key would be your regular key plus the knowledge start date.
Your end date might either be null for a current record or an "end of time" sentinel.
On an update, you'd typically set the end date of the current record to "now" and insert a new record the starts at the same "now" with the new values.
On a "delete", you'd just set the end date to "now".
i've done that.
2.a) version number solves the unique constraint issue somewhat although that's really just relaxing the uniqueness isn't it.
2.b) you can also archive the old versions into another table.
I'm no database guru, so I'm curious if a table lock is necessary in the following circumstance:
We have a web app that lets users add entries to the database via an HTML form
Each entry a user adds must have a unique URL
The URL should be generated on the fly, by pulling the most recent ID from the database, adding one, and appending it to the newly created entry
The app is running on ExpressionEngine (I only mention this in case it makes my situation easier to understand for those familiar with the EE platform)
Relevant DB Columns
(exp_channel_titles)
entry_id (primary key, auto_increment)
url_title (must be unique)
My Hypothetical Solution -- is table locking required here?
Let's say there are 100 entries in the table, and each entry in the table has a url_title like entry_1, entry_2, entry_3, etc., all the way to entry_100. Each time a user adds an entry, my script would do something like this:
Query (SELECT) the table to determine the last entry_id and assign it to the variable $last_id
Add 1 to the returned value, and assign the sum to the variable $new_id
INSERT the new entry, setting the url_title field of the latest entry to entry_$new_id (the 101st entry in the table would thus have a url_title of entry_101)
Since my database knowledge is limited, I don't know if I need to worry about locking here. What if a thousand people try to add entries to the database within a 10 second period? Does MySQL automatically handle this, or do I need to lock the table while each new entry is added, to ensure each entry has the correct id?
Running on the MyISAM engine, if that makes a difference.
I think you should look at one of two approaches:
Use and AUTO_INCREMENT column to assign the id
Switching from MyISAM to the InnoDb storage engine which is fully transactional and wrapping your queries in a transaction