I tried searching online for this...I had a row that I inserted into the database. I removed it. The table has a Unique Key on a particular column. When I try to insert a new row with the same value for the unique key, it fails saying duplicate entry. However, there is no duplicate entry since the row is not there! Is there a way to reset this?
I would like the table to accept values that are unique to what is there right now. I tried to remove the unique key constraint from the table to see if that would work, however, when I added it back, it was having the same issue.
Maybe you perform dirty reading? and the deletion did not commit? try use the read commit option, I think it's called isolation level.
Related
If I try to update or delete one of my tables in my database (and only that table), I cannot do so without enabling safe mode.
Query:
UPDATE booking SET bookingDate='2017-09-20' WHERE id=123456;
Error:
Error Code: 1175. You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column
The problem with that error message is that I do actually have a primary key which is an index and I was trying to use it to update the row, but for some reason my database just doesn't recognise it. I only have that problem on one specific table as well.
I understand that I could turn off safe updates every time that I want to run an update or delete a row, but that isn't what I want to do as I shouldn't have to do that with a primary key present.
I have tried dropping the table and rebuilding it, but that didn't work either.
Update: After a lot of painful research, I've discovered what the problem actually is and updated the title to make a little more sense. I'll put my answer below.
Unfortunately, I'm not able to copy the query that's giving me this problem because it belongs to my company, so I'll have to keep my question very specific.
I have an INSERT INTO ... SELECT query that's returning this error:
Duplicate entry <gobbledygook> for key 'idx_<tablename>'
The tablename at the end is the correct name, but it has this weird idx_ prefix before it that's not a part of any of the tables I'm currently working with. What is that idx? Does it have something to do with the information_schema?
Update: Apparently, I need to clarify something: There is no column with idx in the name.
The numerous websearches didn't reveal much when I was trying to solve this problem, but I did finally figure it out (and JohnH's answer helped me to do this).
I finally discovered that "idx" is not something created by MySQL, but a name that someone else gave to the index. I have never come across a uniqueness constraint on an index that wasn't a key before, so I didn't know where that error came from.
This command showed all of the indices:
SHOW INDEX FROM <tablename>
And I was able to see that non-unique was set to 0 for this key.
To fix the problem, I was able to simply drop the index and recreate it, without adding a uniqueness constraint.
DROP INDEX idx_<tablename> ON <tablename>;
ALTER TABLE <tablename> ADD INDEX idx_<tablename> (<comma-separated columns>);
Whether or not removing the uniqueness constraint is a good idea remains to be seen, but it's also beyond the scope of this question.
"idx_" is a common prefix for index names.
You many have an index that does not allow duplicate values for the column values referenced by that index.
In my case the unique index had duplicate entries even though the column being indexed didn't. I can only think this was caused by a bug. Solution was
Stop the service that writes to the db
Drop the index
Recreate the index
(Do the operation that was previously failing)
Start the service
It's important if you are dropping an recreating an index that nothing can be given an opportunity to insert a duplicate entry while you are doing this. This is why I stopped the service that writes to the db.
I have an app that has to import TONS of data from a remote source. From 500 to 1500 entries per call.
Sometimes some of the data coming in will need to replace data already stored in the dB. If I had to guess, I would say once in 300 or 400 entries would one need to be replaced.
Each incoming entry has a unique ID. So I am trying to figure out if it is more efficient to always issue a delete command based on this ID or to check if there is already an entry THEN delete.
I found this SO post where it talks about the heavy work a dB has to do to delete something. But it is discussing a different issue so I'm not sure if it applies here.
Each incoming entry has a unique ID. So I am trying to figure out if it is more efficient to always issue a delete command based on this ID or to check if there is already an entry THEN delete.
Neither. Use INSERT ... ON DUPLICATE KEY UPDATE ....
Since you are using MySQL and you have a unique key then let MySQL do the work.
You can use
INSERT INTO..... ON DUPLICATE KEY UPDATE......
MySQL will try to insert a new record in the table, is the unique value exists in the table then MySQL will update all the field that you have set after the update
You can read more about the INSERT INTO..... ON DUPLICATE KEY UPDATE...... syntax on
http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html
I need to insert new row into table foo. But before insert those data, I need to check there was already inserted a row for the respective user name. If there has been already inserted, then I need to update the current data with the new data.
I know to do this using PHP if condition. But I love to do this using MySQL functions/statements by just a one line. Please can anyone help me?
For the example, kindly use the following statement. It should be updated.
$in = "insert into foo(username, text) values('user-x', 'user-x-text')";
Mysql_query($in);
When searching for similar questions, I got this post: Similar question with an answer. But I was struggle to use that solution since I don't know, the process occur by that code snippet will get down the server resources like speed etc. Because this script will run about 20 times per user.
Thank you.
I think INSERT ... ON DUPLICATE KEY UPDATE should be able to work
Make username a UNIQUE index, it doesn't have to be a primary key
If I'm not mistaken, DUPLICATE KEY will run only when you have a collision in any of the columns you supply that is either a primary key or unique index. In your case, text column is neither so it will be ignored for collisions.
INSERT... ON DUPLICATE KEY UPDATE works on unique indexes as confirmed by the MySql docs
I have a table that is in production. I realize that some of the columns should be unique. Is it safe to go into phpMyAdmin and change those columns to make it unique?
ALTER TABLE `foo` ADD UNIQUE ( `bar` )
Follow the below steps to apply unique column value from phpmyadmin panel:
Go to the table structure. Click on the unique keyword as like below -
Click on the ok from confirmation box -
Unique value constraint for column will apply.
Or you can run mysql query:
ALTER TABLE user ADD UNIQUE(email);
You do not have duplicates -> will apply the key without issues
You do have duplicates -> will give an error message, nothing happened to your data
All is unique, except several rows with NULL in them, unique constraint is still applied, as NULL is not checked when checking for unique values (you can have the entire table have a NULL value in a unique field without any error message).
One more thing, if you have a prod DB, you must also have a dev DB which you can test on without fear, right?
If there are already some duplicate values in those columns, then this will generate an error. If there aren't any duplicate values in those columns, then you will be fine.
It will only be a problem if the pre-existing values on the table are not unique, otherwise I don't think there will be any problem.
I had this problem and my values were not unique. I also couldn't find an easy way to edit this problem in PHPMyAdmin. Here's how I solved it:
I clicked into the table I needed to update
I exported the table, changing it to be a CSV export and then edited
it manually to update the non-unique values.
Making sure I was still in the table I had exported (because I
wanted to keep the headers intact), I imported my newly saved CSV
Hope that saves someone some time in the future.