On one occasion on v5.7.5 I was able to reproduce this by rapidly clicking the upload button on a server that was seemingly laggy. But I've not been able to cause this to happen reliably, usually the additional Upload button clicks just cause additional versions of the file, but sometimes it can cause multiple current versions of file with the same name. This suggests to me that a race condition is at play.

I've just seen this error on a Confluence 5.7.

still the same in 5.8.18.
Atlassian, you should either re-open the ticket or clone it. This is not 'resolved'.

as do we, in 5.8.14. Is there a resolution, if the original error was fixed, to fix the data?

Same here on 5.8.10.

Same here on 5.9.4

We get this error on 5.9.4

We get this on 5.8.4

I get this on 5.8.10 too

got this on 5.8.10 of Confluence too

Got this on 6.2.3!

Seeing this in 5.1.5

We see this on one of our 5.3.1 instances.

We see this in 4.3.7, too.

one was related to an attachment. It was named, so I was able to find it. It existed twice with the same name attached to the same place. For some reason, the upload of the attachment has loaded it twice (which should not happen). I was able to delete one of the duplicates.
The suggested SQL (farer above in this thread) did not work for me.

Besides of attachments, the error can also happen upon notifications:

2013-04-26 10:17:54,153 ERROR [StreamsCompletionService::thread-1346] [com.atlassian.hibernate.HibernateObjectDao] findSingleObject Uh oh - found more than one object when single object requested: [com.atlassian.confluence.mail.notification.Notification@17581f1, com.atlassian.confluence.mail.notification.Notification@17581f2]

I don't know what throws it

We see this in 4.3.2. Support referred us to the knowledge base article, but it does not apply for our version.

Can confirm this is still an error in Confluence 4.3.3:

2013-01-10 09:01:20,204 ERROR [http-8090-14] [com.atlassian.hibernate.HibernateObjectDao] findSingleObject Uh oh - found more than one object when single object requested: [Attachment: AdmBrukerStruktur2.png v.1 (19398895) , Attachment: AdmBrukerStruktur2.png v.1 (19398899) ]
2013-01-10 09:01:20,214 ERROR [http-8090-14] [com.atlassian.hibernate.HibernateObjectDao] findSingleObject Uh oh - found more than one object single object requested: [Attachment: AdmBrukerStruktur2.png v.1 (19398895) , Attachment: AdmBrukerStruktur2.png v.1 (19398899) ]

jplumhoff That's quite surprising - the fix shipped in 4.1, and we haven't seen any regressions around this in our own testing. Can you please create a support request, so we can dig into why you're still affected?

I'm running 4.2 and still seeing this error.

For those not moving to Confluence 4, workaround available here:

Multiple AttachmentData objects were returned when only one was expected for attachment

I'm seeing this in Confluence 4.0.3 now.

Still getting this bug in 3.5.4 Any idea when this will be corrected? It is now 4 years and 4 months since this bug (classified as 'Major') was opened....

Going on three years for this bug to be open....

We're getting hit with this on new pages throughout our wiki every couple of weeks.

We need some utility that can go through our database and proactively deal with the issue, instead of waiting for users to be blocked in their work as they attempt to access wiki pages.....

Our upgrade to 3.1 is failing during the database update on initial launch. I've just filed a report on this, so it is unknown if it is related to this bug, which I've received two different reports of in the last couple of weeks.

What I am worried about is that creeping corruption in our database may eventually block an upgrade that tries to do something like adding constraints to the database.... A utility that validates the contents of the database, and applies known fixes to known problems, could be very important to large wikis.

I suggest we add a unique constraint to the attachmentdata.attachmentid column. That would stop this situation happening in any new instances. It might create another bug, since there's presumably an application logic flaw that attempts to insert two data rows for the one attachment, but this bug should be easier to find once the unique constraint causes an exception to be thrown immediately by the second insertion.

Even though this issue has been assigned and waiting in the 2.5.x queue for a while, there was no immediate necessity to fix it (when comparing it to other issues importance). It has been decided to remove the fix version and reschedule it later.

Please see the most recent post from Christian Hansen on CSP-7087 [16/Feb/07 05:02 AM]
It seems as a particular ID from the ATTACHMENTS table is not referred in the ATTACHMENTDATA table at all. Instead of that, two copies of the same ID exists there.
User resolved the problem by changing one of the duplicates to an expected value and problem was solved. However, two copies of the same version of an attachment still remained on a page.