I've run into a snag with a script I'm working on to rename jpeg attachments within an SDE (PostgreSQL backend). The script downloads the original attachment, gets the date from the exif data, renames the local copy of the photo, then tries to remove the original attachment using arcpy.RemoveAttachments_management() and add the new, renamed attachment.
The script runs just fine when testing it out on a feature class and it's associated __ATTACH table in a file GDB. When I run it against a versioned feature class that is in our SDE, however, it does not remove the original attachments. It does add the renamed photos as expected, in effect doubling the number of attachments (ie, "Photo1.jpg, Photo2.jpg" becomes "Photo1.jpg, Photo2.jpg, 02-13-2017-Photo1.jpg, 02-13-2017-Photo2.jpg").
I have verified the match table I'm using for RemoveAttachments_management() is being created correctly. If I try to run either the Remove Attachments geoprocessing tool or it's python equivalent in the python console window, it "succeeds" but gives the warnings "Cannot remove attachments for OID = 1", etc and doesn't delete the attachments.
I can remove the attachments manually just fine, either through the Attachment Manager or by manually deleting the records in the __ATTACH table.
Is anyone aware of anything that would cause RemoveAttachments_management() and the associated GP tool to not be able to remove the attachments in a versioned SDE?
I had the same problem but found out you must "Unregister as Versioned" the _ATTACH table. Your main feature class can stay versioned. When you create attachments on a versioned feature class the versioning carries over to the _ATTACH table that is created. In short, the _ATTACH table cannot be versioned for the Remove Attachments GP tool to work.
Interesting. My gut feeling is that having the feature class versioned while the attachment table is not versioned could lead to headaches down the line, but that's only a guess. It sounds like you haven't run in to any issues? Or do you just temporarily unregister the attachment table when running the tool?
My work-around was to write my own function to delete the attachment, treating the __ATTACH table just like any other table and using an update cursor to remove the desired row.
In my case all attachment additions and removals are done through GP tools and never through the manual editing method so an unregistered _ATTACH table is no problem. If manual attachment editing is needed then yes, I would unregister and re-register before and after the GP tool is run.