I have a VB6 program that adds a column to an MS Access database thusly:
alter table x add column y long constraint z unique
The program goes through a number of databases without error; however, on the one that I am looking at now, it gives me "The changes you requested to the table were not successful because they would create duplicate values in the index, primary key, or relationship..."
In case it makes a difference, I add values to the column by forming a recordset of the primary key and new column values, then going through each record to add a value to this column. I do recordSet.updateBatch when I'm all done.
If I remove the constraint, it completes normally; I have put all 1600 values into a spreadsheet, sorted by the values I've added, and used a formula to check for duplicates. There aren't any. All rows get a new value, none of the new values are the same as any other new value.
Are there other reasons why I might get this error? I really don't want to remove the constraint, but I don't know how to get past this.
Since you're certain you're not attempting to insert rows which violate the table's index constraints, perhaps you have a corrupted index. See whether Compact & Repair cures the problem. But first make a backup of the database.
You could also recreate the table in a new database and test it there.
You can find further information about corruption at Tony Towes' Corrupt Microsoft Access MDBs FAQ.
Related
Bit of a strange one - I haven't changed the config, database, PHP code for this site for about 8 years. The whole time the guy I made it for has been adding, removing, changing stock with no issue, and suddenly today gets this error:
Duplicate entry '2541' for key 'PRIMARY'
executing (inserted generic values for the texts):
INSERT INTO stock (id,title,category,description,price,last_update,sold) VALUES(NULL,'Item name','72','Item description','0',1613723525,'no')
Searching around seemed to suggest this was a common problem when the primary key is not set to auto increment - makes sense. However, checking it out through phpMyAdmin, it definitely is.
Is there something in the index being set to primary rather than unique?
There are 5 other tables on the database but none are linked (as in hard links through the SQL, PHP handles all the cross-table stuff).
I checked and indeed there IS an item in the stock table with ID 2541 already. So why is that NULL AUTO_INCREMENT value converting to an existing id?
EDIT
I noticed that a table I created more recently (via MySQL Workbench probably) has a different setup for the indexes, with the addition of an id_UNIQUE index - do I need one of these on the stock table that is causing issues?
Based on your description and your comment "Interestingly, each time I refresh the ID it is attempted to insert (and failing on) increments by 1", I suspect that somehow the seed for the autoincrement for that table got changed to some value that was inserted at some time before.
How exactly that could happen I don't know.
Now, each time you attempt to insert a record this internal counter increments, so you see in the error message that the number increases (2541, 2542, ...) When you attempt to insert a row the internal counter increments regardless of whether the transaction is committed to the database or not. In your case the insert operation is rolled back, because the generated value violates the unique constraint and the internal counter keeps growing.
To change the seed you can run the following statement:
ALTER TABLE stock AUTO_INCREMENT=1234567;
You'll need to set it to the current MAX value that exists in the table, so that new entries that the system attempts to insert do not conflict.
See also How to set initial value and auto increment in MySQL?
This answer shows how to change the autoincrement seed in MySQL Workbench and in PhpMyAdmin. Maybe somebody did this accidentally and didn't notice.
I have a very large table (dozens of millions of rows) and a UNIQUE index needs to be added to a column on that table. I know for a fact that the table does contain duplicated values on that key, which I need to clean up (by deleting rows/resetting the value of the column to something unique that I can automatically generate). A plus is that the rows which are already duplicated do not get modified anymore.
What would be the right approach to perform a change like this, given that I will be probably using the Percona pt-osc tool and there are continuous deletes/inserts on the table? My plan was:
Add code that ensures no dupe IDs get inserted anymore. Probably I need to add a separate table for this temporarily, since I want the database to enforce this for me and not the application - so insert into the "shadow table" with a unique index in a transaction together with my main table, rollback all inserts that try to insert duplicate values
Backfill the table by zapping all invalid column values which are within the primary key range below $current_pkey_value
Then add the index and use pt-osc to changeover the table
Is there anything I am missing?
Since we use pt-online-schema-change we are using triggers for performing the synchronisation from the existing table to a temp table. The tool actually has a special configuration key for this, --no-check-unique-key-change, which will do exactly what we need - agree to perform the ALTER TABLE and set up triggers in such a way that if a conflict occurs, INSERT .. IGNORE will be applied and the first row having used the now-unique value will win in the insert during synchronisation. For us this is a good tradeoff because all the duplicates we have seen resulted from data races, not from actual conflicts in the value generation process.
I have in Microsoft Access a linked table to an ASE Server.
On the server side, the table has no primary key or identity columns.
And has a trigger on insert that validates new entries, so that when the entry is not validated it deletes the entry from the table and writes to "table"_ERR to let the users know what error was produced.
When linking it to Access a composite key is created using 10 columns.
I have this same setup in 10 different tables (all with triggers all linked to Access)
In this particular table when trying to insert/append records to the table through Access i always get the error message:
Single-row update/delete affected more than one row of a linked table. Unique index contains duplicate values.
This error occurs when both table and table_ERR are empty and i'm only trying to insert 1 record.
If I disable the trigger i have no problem inserting records through Access
I have similar triggers in other tables that are working correctly.
What can be causing this issue and does anyone know how to solve this?
I have read that MS Access can mess up the ##identity, even so none of the solutions presented online seem to work.
links : https://groups.google.com/forum/#!msg/microsoft.public.sqlserver.programming/McHdRpPKMhs/SlyObU8w7JMJ
Stop Access from using wrong identity when appending to linked table on SQL server
Thanks in advance.
EDIT: if i try to insert the records directly from a management software (like Aqua Data Studio) there are no erros
Without knowing more specifics about your data itself, it is difficult to say why this might be happening.
However, it sounds like in this specific instance for this specific linked table, your 10 columns are not unique enough to prevent non-distinct rows from being selected.
Suggested fixes:
Add a primary key. Honestly, probably the best and easiest choice.
If for some reason you cannot add a new column to (or alter) your table; you may be able to re-link your table, and re-choose your 10 columns so that they are more unique.
Beyond that, I think we would need more information.
Just out of curiousity, what is the reason for having no key?
I have a split form view with data coming from linked sql server (2008).
How do I go about updating the record?
Currently, it will not let me change anything in the text boxes i assume this is because the data is coming from linked tables?!
In order to update do i have to create command and coonn objects and program it in the usual vb manner?
And if so, what is the syntax for referencing the linked tables when creating the update query?
On my split form I dropped a button on there and I can see options to make it run macro, run code, etc etc, which one is suitable?
many thanks,
KS
First make sure the table was not linked read-only.
When you link to a remote table, Access will make it read-only if it is unable to identify a primary key or another combination of fields to uniquely identify each row. Sometimes, but not always, it may ask you to tell it which field(s) to use as the primary key if it is uncertain.
But this issue is simple to check. Open the linked table directly in Datasheet View and see whether you can edit any values. If not, re-link the table and look for an option to inform Access about the primary key.
If the link is not read-only, make sure your form's Allow Edits property is set as Yes.
Also you could try a simple form rather than a split form to determine whether something about the split form is causing the problem.
Solution:
MS Access barfs when trying to register tables with a primary key of type BigInt which is 8 bytes, Access can only handle Ints of 4 bytes. Workaround is below:
Drop the constraint (bigint PK) in SQL table
Create a new primary key (int) with identity seed
Link the table in MS Access
Drop new constraint (int PK) & Re-Add your previous constraint (bigint PK) in MS SQL
Voila!
I am trying to restore a DB using an SQL script, but things foreign key constraints get in the way
I am taking a MySQL DB and bringing it over to PostgreSQL.
Since the MySQL create table syntax ended up being quite different, I took another PostgreSQL DB with the same schema, but different data and restored the schema only, from that.
In other words, I now have a database with tables, constraints, sequences and all that shnaz but no data inside.
So, it's is time to restore data.
I take a backup of the MySQL DB with phpMyAdmin (data only) as an SQL script (pgAdmin does not seem to accept zip or gzip files for some reason) and run the SQL script.
Now, this is where the problems start to happen, it's only natural, I am going from MySQL to PostgreSQL, so syntax errors are bound to happen.
But, there are other non syntax related problems to, like this one:
ERROR: insert or update on table "_account" violates foreign key constraint "fk_1_account"
DETAIL: Key (accountid)=(2) is not present in table "_entity".
So, yeah, basically, a foreign constraint exists, the query is trying to insert data into the _account table, but the corresponding data has not been inserted into the _entity table yet.
How do I get around that? Is there a way to make pgAdmin3/PostgreSQL disable ALL OF the constraints, insert the data, and then re-enable the constraints?
A syntax related error I encountered, was this one:
INSERT INTO _accounttype_seq (id) VALUES (11);
The PostgreSQL equivalent of that statement (if I am correct) is
ALTER SEQUENCE _accounttype_seq INCREMENT BY 11;
But, it's a bit of a pain to run through the whole script and change all 200+ Sequence insert statements. So, I am being lazy here, but is there an easier way to deal with the sequences as well?
Or, do you guys have any suggestions for a different set of tools to make this easier?
Thanks for your time, have a good day.
Do not try to get around the foreign key constraints. That is the way to make sure the data is bad.
First look at the constraints and make sure you are inserting to the tables in the correct order. If _entity is parent of "_account, then it should be populated first.
Next you need to have the script move any failing records to an exception table. Then you can look at them and see what the data integrity issues is and if you need to throw the records away permanently or try to figure out what the missing parent value should be. If it is critical data such as orders where the customer no longer exists (possible in any system that didn't have correct fks to begin with) and you must keep the record and cannot determine what the parent value should have been, you can create an 'Unknown" record in the customer table and assign all bad orders to that customer id.
And manually changing the alter sequences shouldn't take long even if it is boring. There wil be plently of other things you need to handle manually in a conversion of this type.
I would try to find a data import tool for PostgreSQL - I live in SQL server world where I would use SSIS but you need the equivalent of SSIS for the PostgreSQL world.
Aparently the foreign keys weren't actually enforced in MySQL (maybe because of using MyISAM) or the generated SQL just does it in the wrong order.
If it's "only" the wrong order, I see two possible solutions:
edit the generated script and either move all FK definitions to the end of the script
Edit the definition of each FK constraint and set them all to initially deferred. Then run the script as one single transaction with only on commit at the very end.
Edit (because this is too much to be put as a comment)
Using SET CONSTRAINTS ALL DEFERRED will only work if the constraints have been created with the option DEFERRABLE.
To run everything in one single transaction, you have to make sure you have turned autocommit off. Then simply run the INSERTs and at the very end issue a COMMIT. A ; will only commit if you have autocommit on.
If you want to be independent of the autocommit setting, then start your script with [BEGIN][1] and make sure there is only a single COMMIT at the very end.
BEGIN DEFERRABLE
INSERT INTO table_one ... ;
INSERT INTO table_two ... ;
.....
COMMIT;