Effectively, it looks like Drupal is trying to save a file, but there's no filename or filesave, so it's failing as a duplicate of the first time this happened (and was stored in the DB).
I think the PDOException is just a symptom, and the real problem is that an invalid file object is being passed along.

I can't be sure whether my client is trying to upload/delete/change a file, or just entering text data into other fields, but this comes up frequently and seemingly at random.

I am also having this issue when trying to import nodes from a D5 install to D7 in a batch operation. When node_save is getting called on nodes that have file fields attached to them I receive this error. I have added a little debugging to file_field_presave as was mentioned in the previous thread and what I discovered is that it appears that file_load is failing. I dump the results of $item in the forach loop I get Array ( [fid] => 7412 [display] => 0 ) so a fid is being passed to file_load. Then if I dump the results of file it seems to have nothing in it... I will look into the file_load function a little deeper but I thought this information may be helpful.

Be sure whatever user is running the script has the right permissions on the files directory and all subdirectories. If you are running something as drush then it runs as the command line user so that user needs to have read/write on the files directory (possibly via unix groups management).

Subscribing. Getting this same issue on D7.10 core. Additional I can confirm it's happening when I've all cache combo enabled (Varnish server, Boost, APC & Memcache), but definitely getting this because of the Memcache. It happens often right after Remove an image and then placed a new one. A popup with the message:

User tries to do something in Drupal.
Drupal times out.
User presses back button.
User submits the same form again.
Error and corrupted data are the result.

Possible Solution:

Open .htaccess file and add this line to stop the timeouts:
php_value memory_limit 64M

Now, to delete the corrupted records, go into your database and find the corrupted item, then delete it. In my case, it was in the "views_view" table. It's easy to find since the name of the view is stored in that table.

If someone knows of another table where stuff needs to be deleted, please let us know.

The closest I come to the reported comments, is that I removed image-files from a folder drupal puts the attached files/images in (as I later discovered). I wanted to remove these image-files in order to clean up the folder from a couple of copies (image_0.jpg, image_1.jpg, ...) I did not (knowingly) put there myself.
Finally I could reproduce the notification and made it go away. Perhaps someone can use this information to prevent this notification from happening in the first place.

----------------------------
I used the attach_file module (filefield_sources-7.x-1.4.zip) to attach a different jpg-image (<9K) to a series of nodes through an image-field. This image-field was part of a bookpage content type form with a bunch of other fields. The image appears via a cck-block in the second side-bar on a webpage above the book navigation. I cannot give a weblink, because I am still developing the site on my localhost.
Within the book type form the images are uploaded from the folder “sites/default/files/attach_files_[name]”. I used the name “hoofdstukken” (=Dutch for chapters) and assigned the name "attach_files_hoofdstukken" to the folder where I put the images. These assignments were done in the file attach section of the form that controls the image-field. In the same form I assigned the folder "sites/default/files/hoofdstukken" to the folder where drupal should place the attached image-files.

As for the reported notification/error it took me a while before I figured out how to reproduce it and what to do about it. The information in the above comments helped. I used phpmyadmin to check the database entries.

------------------------------
I observed that when attaching an image-file in the book content form to the image field, data is stored in the database in “prefix_field_data_[name of field]”. For example: with "prefix=drup_" and “name of the field=field_image_deel_een", the database has an entry “drup_field_data_field_image_deel_een”. In this database entry the column “entity_id” has the number of the node that is attached to this specific "field_image_deel_een". The column “field_image_deel_een_fid” has the “file id number” [the file being an image file] which is reported/managed in the database entry “drup_file_managed”. The entry “drup_file_managed” not only has the file ID (fid) but also the specific “filename” and the uri. The database also has a revision entry “prefix_field_revison_[name of field]”: in this specific case “drup_field_revison_field_image_deel_een”

------------------------------
Putting the above information in a scheme gives three entries/rows in the database where information about the node and the attached image is stored.

prefix_field_data_[name of field]: contains “entity_id”=node ID; “[name of field]_fid” has the “file id number” where in my case the file is an image

prefix_file_managed: contains fid; specific name of the file/image; uri of the file/image

------------------------------------------
When for example the attached image.jpg is deleted from a node, I expected that all the information about the connection between image.jpg and the node is removed. But it isn’t.

First of all image.jpg is not removed from the folder where drupal stored image.jpg when it was attached. De-attaching image.jpg from the node is recorded in 1 (the node ID is removed), but not in 2 and 3 (the fid and the image remain).
So when re-attaching the same image.jpg to the node by selecting it from the attach_file folder, drupal generates a copy (image_0.jpg) in de folder where the attached images/files are placed (in my case sites/default/files/hoofdstukken). In the admin node-form through which this image.jpg is re-attached the original name shows up: image.jpg (which makes sense).
When deleting the re-attached image before saving the node-form, drupal removes the copy (image_0.jpg) from the folder. However when deleting the re-attached image.jpg through/in the node form, after having saved the node-form, neither of the images (image.jpg or image_0.jpg) disappear from the folder.
And when re-attaching the same image.jpg to the node (after having it removed) by selecting it via attach, drupal puts another copy (image_1.jpg) in the folder. Again only the name of the name of the re-attached image is reported in the node-form (which makes sense). So the deleted actions were not registered in the database under entry 2 and 3 (see above list). And after having attached, removed an re-attached the same image (with saving in between), the folder where drupal stores the attached images/files contains a series of copies of the same image: image.jpg, image_0.jpg, image_1.jpg, image_2.jpg ....
-----------------------The showing up of the notification
When deleting one of the copies from the folder where drupal stores the attached images (to clean up the folder) and when re-attaching image.jpg to the node, drupal completes the original series and makes a new copy.
However when deleting all of the images and image-copies from the folder and then trying to re-attach the same image.jpg in the node-form, the attachment does not complete itself: on the form page the “please wait” image/spinning circle sign remains spinning. At first I thought of a time out problem. When saving the node-form, the reported PDOException notification shows up: apparently drupal is missing the older copies (place holders?) and therefore cannot make the necessary copy (image_x.jpg) to be re-attached to the node.

Removing/preventing the notification
This PDOException notification does not show up again, and image.jpg can be re-attached to the node, when all the info in database entries 2 and 3 (see above list) about the specific image is deleted. I used phpmyadmin to do that. Be sure to make a backup before changing the database in case you need to go back!

In addition: when using an default image for an image-field, drupal stores a copy of the attached/uploaded image in sites/defaults/files/default_images. Removing or cleaning up a default image is done by removing the corresponding row in entry 2 together with the image and its copies from the default_images folder. Drupal itself generates this default_images folder.

I am not much of a programmer to figure out a script to have drupal remove all the information when removing a previous attached image or a file through a field to a node. I suppose it can be done. Manually cleaning up a site as indicated when developing it is not so hard.

I don't normally use Parallels Plesk Panel which has a curious habit of duplicating folders during a file/folder move. For example it created an /includes/includes folder with new content leaving the original content in /includes. I removed the duplicate files and folders and it solved the problem.

fyi this can also be happen if your php tomeout/script runtime is too low. i had around 60 but did a huge batch job creating nodes and some had a lot more data (images) to it. these big nodes where what cause the error here.
so the solution was raising timeouts for the import.

I have this error when I remove an image and then re-upload the same one. Using Drupal 7.12
(I also have Redirect module installed. )
EDIT: If I try to upload the image again, it usually works the 2nd or 3rd time.

the reported exception was returned when
-uploading of 1 or more images with plupload, media browser plus and media gallery
-uploading of 1 or more images with media browser plus and media gallery
-uploading of 1 or more images with media gallery
-uploading of 1 image, with unique file name, with media gallery

This error is related to php.ini
My site was in sub folder, I copied the site the root, and by mistake I did not copied the php.ini, and I got this error ... I think its something related to the memory !

I have the same error while uploading files.
But I don't think my problem is due to case insensitive, becase I just upload the same file using FILE_EXISTS_RENAME option in file_save_upload(). And the patches's versions are too many to make me disturbed. So My temporary solution is to override file_save_upload method.

"PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'public://7.jpg' for key 'uri':" YOU will get this ERROR if you will try to upload an image with a specific name for example 7.jpg but on your host an image with the same name is already there!!!!! SOMEBODY HELP PLS!!!

I had a similar problem today in trying to figure out how to save files. The file paths weren't being saved correctly using tokens. Eventually it did work, but I kept "removing" the file and reloading it and then I got this error. When I finally figured out the file paths correctly, I created a new node with a different file and it worked. I then deleted the node that I had been "testing" with repeatedly and ensured the doc was deleted in the file path and then re-created the node in a new unit of time and I no longer got this 1062 duplicate entry error. Hope that helps.

i have file field that i have removed from this particular form, because i want to handle this file field upload process in another form but still have files attached as fields in my entity. and use all field logic too.

the thing is that even if i have removed that field_files -element from form, and in my best logic that shouldn't get validated or raise any kind of error.

It happens when I'll go to: node/2/workflow and I'll change the workflow state to different one.
Not sure from where it comes and if it's related to Workflow or some other modules.
--
The previous one happens when the node is saved using ctools wizard and even the file wasn't included, following queries were executed:

I experienced similar message when import user with User Import Framework.
I had tried to import test files with invalid data and the imports failed.
Believing that I had created bad data in the database, I ended up deleting all of the data in the user fields I had added that were being populated by the import, and tried the import again, it worked with no errors.
Rik

June 9 2012
Drupal 7.12, all updated modules, with a copy of the server installation on my home machine, both Fedora 16 and Ubuntu Precise.

I found that /sites/default/files, for me in Fedora 16, I had to sudo chown apache:myusername files and the fault disappears.
In Ubuntu I had to sudo chown www-data:myusername files
I have also found that the file /colors in /sites/default/files has to have the same ownership as /files and /ctools in both.
A fresh drupal install does not seem to have this problem.
I hope this helps someone else.

I received the same error when trying to save a new view with/without a block. Working with WAMP on a test site. Strange because I've been making and saving views with no issues before.

#66 patch did not work for me. I also deleted corrupt view in database before applying patch.

Update:
Possible fix or just a fluke. After three attempts at trying to make a new view and saving I kept getting the same errors. When I went to the Views list it wouldn't let me delete the view. So I went back to my error page and refreshed it, and surprise no error! I was even allowed to delete the view. My new saved view has no errors so far...

@aneko if you have received this error using Views, please report separate issue against Views module, because the same error doesn't mean the same problem. This one is related to Drupal core and patch is working for those who are experiencing the same problem.

Background: I also am in the process of upgrading a Drupal 6 site to D7 Panopoly and am receiving this error whenever I upload a file with the same filename of an already uploaded file to an image field. New files with unique filenames are not a problem. Interestingly enough, even the though the error appears, the file is uploaded to my sites/default/files directory + inserted into the DB. If I save the node and edit it again, it appears in my image field list.

I have a bunch of modules enabled that could be effecting this (filefield_sources, insert, transliteration, content_lock, save_draft, redirect), but I've disabled all related modules and the error persists.

I'll try messing around with killing node_revision (I see that mentioned in other issues) and will report back in I have any luck. Happy to run any tests/assist in debugging in any way deemed helpful.

I started having this problem on a website when editing nodes with a lot of images that had been imported. To fix I installed the filefield_paths module then set the field of the image to change the filename to a random hash, I then ticked a box to retrospectively update all paths (this took a while). Now when a file it uploaded the filename automatically gets given a random hash.

@mgifford: No dear..I was a little short of time and was looking for a quick fix..fortunately I got the root of the error in my project it was the remember me module which was trying to insert all zero values in the file managed table while a user logs in and hence thwrowing "duplicate entry error" I removed the module and things are just fine now.. :) Checkout for the newly installed contributed modules.. may be you too get lucky!! Hope this helps..

This is unbelievable! there are 4 or 5 threads about this issue all claiming that it is this or that module. I can't believe that just installing a module hoses the whole install and that that! No answers ...

Drupal 7 == Windows Millennium Edition (ME).

Drupal use to be for smart people and good coders, now it is like medicine or the law made intentionally complex to feed the egos of weak scared people.

@pigpenn drupal is built by volunteers, so instead of posting unconstructive comments why not help track down the course of the issue or review the posted patch as obviously you are encountering the issue.

@pigpenn:
This issue is actual MySQL database error, not Drupal it-self and it's too general to tell exactly what happened. So there can be even 100 threads of the same error, each can be caused by something else.
Sometimes it's caused as it's stated by 'Integrity constraint violation', so please use only one Tab at a time and don't refresh/re-post your page again, because probably your record has been already created.
It's best to not install too many modules at once. Start from scratch and install only stable modules with more than 1000 usage statistics and check if the error happens again.
If you are not developer, please use Forum, you'll find there simple solutions to your problems.

I get the same error but not for any of the above modules or reasons, which makes me think it is a MySQL error. I am using db_merge with the expectation that the module will see if there is a duplicate and if such is found, do an update rather than an insert. It appears that (unless there is an error here I am not seeing) it is deciding that there is not a duplicate and doing an insert - and the insert is what is throwing the error. The key here is the exact unique key on the schema in my module.

Since the title of this thread is the exact message I am getting and is currently active I decide to add the issue here, but perhaps I need to add it with db_merge in the title of a new issue. Please advise or feel free to cross-post/move it if that is appropriate - I just do not want to create duplication and confusion.

I am getting the same error as stated in the title of this thread, but I think I have found the problem and how to fix it.

I created a script to batch create nodes based on data I have in a spreadsheet file. If there are images, then those are handled accordingly. Here is a small excerpt from my $file object when saving a node:

The error, I believe, is in the file_copy() function. file_copy() checks if the file exists and renames accordingly. However, what is does not do is check if that unique filename already has an entry in the database (url field of the file_managed table).

The reason this is happening is the file names in the public:// directory are out of sync with what is reported in the database. Theoretically, if you have image1.jpg in the file folder and public://image1.jpg in the uri field, then the renaming strategy for file_copy should work fine. But what happens when image1.jpg actually gets deleted (for whatever reason)? Then the next file that comes along is image1.jpg. Because it actually does not exists in the file folder, file_copy does not rename it and it populates $file->uri with public://image1.jpg. And then we get the error as shown in the title.

I think adding the validation logic to file_copy() (or whichever function should handle that logic) to not only check if the filename is unique to the files in the folder, but also in this table, will solve the problem. Indeed it has solved it for me.

In my script I append a unique string to the end of my title before I let file_copy manage it to avoid this alltogether.

I can't seem to find a function to check if uri exists and then update the record.. or maybe just delete the record and build a new one....I could generate a unique name as Gastonia did but then the old record never gets cleaned up in files_managed table. A check via a SQL statement seems excessive but does anyone have a better solution?

I was attempting to add default image avatars to new nodes, through hardcoded FIDs, but these images had been deleted due to file_managed usage = 0 previously and I didn't notice. I've re-added them, and now my imports work fine.

Sorry for the false alarm. Ignore #105, although better error warnings would have made this easier to debug.

Another D7 patch. Previous patch had bad paths. Here's a merge of these three (new is Dave Reid's unset fix in presave) to prevent PDO warnings. Might want to add a watchdog though, as not everything will fail silently.

I just updated to 7.21 and had to reapply patch #108 (the one that failed Simple Test). I tried the updated link in #109, but that did not work for me even after clearing cache. Will the patch in #108 be added to core?

@marcingy - agreed, but... What was the last D8 patch in this queue? There hasn't been one that I could see.

This issue hasn't made much progress in D8 and is still stopping folks in D7. I was trying to track down if there is any code relationship between the last patch & D8 and really didn't find any commonality.

Perhaps this is a case where it isn't appropriate to wait till we fix it in D8, before addressing it in D7. There do seem to be useful patches proposed for D7.

I, too, am not clear on how things get officially patched in core D7. I do understand wanting to make sure this is not in D8 or at least is fixed, but I'm hesitant in going live in D7 with a bug that won't allow new content to be added without an image. This is a show stopper for me with each D7 upgrade and I need to reapply patch #108 each time.

@liquidcms, did you mean patch #108 worked? I don't see a patch on comment #10.

guys today after trying to add a content of a particular content type i got the error below, all other content types work fine.

recently we moved from another web server to a new dedicated server. could this have caused this? ive made sure files folder has permission 777
i can see that everything in the root folder and all subdirectories are owned by user 'ftp' and group 'ftp'

these correct? i dont think it would be a permission issuem its database related correct? sorry my knowledge isnt great here

If anyone is still wondering why this might happen, we encountered the issue when a file field referenced a file that no longer existed. Make sure you're file references are clean, and you'll avoid at least one cause of this problem.

@Dave Reid I'm also concerned about this, but I didn't realized a better way to fix this yet.

In the beginning I tended to make a query to the file_managed table in order to make sure that there isn't already an entry matching with the current uploaded file and update its name if it was already in use but this brings performance issues.

For sure we can go further to find a final solution for this issue. Although I think my proposal will handle this in the most of cases. At this moment I think it's more efficient than what we already have.

What do you suggest? I really appreciate to discuss a better way to fix this.

Happy to try diagnose this for 8.x, but struggling to reproduce the problem based on the some of the comments re: file fields on user entities. Does anyone have some clear instructions to reproduce. Thanks. #drupalsouth

I had the same problem as the title of this issue, in a panopoly installation when going to "Apps". After set chmod 777 to sites/default/files/apps/panopoly_demo , panopoly_faq and panopoly_news it worked fine!

I'm also at a loss. This problem returns with every D7 update and I have to repatch using #108. I'm about to go live with this site, but am concerned due to this problem.

Since this is now closed (?), I will roll back #108 and test with the referenced patch mentioned by @marthinal in #151. But that issue has not been touched in 3 months and it last failed. :( I'm fairly new to Drupal and am really unclear how approval happens. This patch has been working for many and has been ready for over a year. D8 or not, it is holding up D7 sites.

If #151 suggestion works or not - I will report back here. If it doesn't I'll go into more details for @alexkb in #144 above.

Just to be sure I started fresh, I went to my dev site and updated to 7.24 -> 7.26. I tested to make sure there was a problem adding a new node without the optional image. Lo and behold - no error! It worked without applying #108 patch.

I had the same problem. I solved this by mentioning correct credential in Settings.php file. The problem was i gave wrong username, pwd, host name. So guys, Before u do all research, Plz check whether the given credentials are correct or not.

Here we are giving the ‘name’ column’s value as “user name”. So first time it wont show any error message. But next time if we submit the form, the ‘user’ column’s value will be repeat again as ”user name”. so this error message will come. In Data base we haven’t allowed for DUPLICATE entry for ‘name’ column. That is the problem here. We can resolve this in two ways,
A) Allow the duplicate value for the particular column in database
->Uncheck the PRIMARY KEY
B) Get the run time value for the particular filed (with the existence validation with DB)