Hi Sven,

This is a dated reply, but I wanted to check if you were able to get around the error.

I checked your stack trace and did the following to grab a little more information about the issue.

I decompiled the EPiServer.dll assembly (Version=7.19.1.0) in the bin folder of one of my local installations. I checked the CleanUnusedAssetsFoldersJob type in the EPiServer.Util namespace. It's got an Execute() method as listed in your stack trace.

If you take a look at the body of the method, there's an IList<IChangeLogItem> called "changes" that we iterate over. Each IChangeLogItem is cast as type ChangeLogContentDeletedItems. Then the ListOwnedContentAssetReferences() method is used to return a collection further cast as IEnumerable<ContentReference>. We iterate over the associated ContentReference instances using the following foreach body.

foreach (ContentReference contentLink in (IEnumerable<ContentReference>) this._contentListDb().ListOwnedContentAssetReferences(((ChangeLogContentDeletedItems) changes[index]).DeletedIdentities))
{
  this._contentRepository.Delete(contentLink, false, AccessLevel.NoAccess);
  ++num;
  if (this._stopSignaled)
    return "Stop of job was called. Number of deleted asset folders: " + (object) num;
}

The call to Delete() is not surrounded by any exception handling so that would explain why you're getting an immediate stoppage.

On the sql side of things, I looked at the [tblContentProperty] table and scripted out the foreign key constraint that is mentioned in your stack trace, see below.

ALTER TABLE [dbo].[tblContentProperty]  WITH CHECK
ADD  CONSTRAINT [FK_tblContentProperty_tblContent2] FOREIGN KEY([ContentLink])
REFERENCES [dbo].[tblContent] ([pkID])
GO

ALTER TABLE [dbo].[tblContentProperty] CHECK CONSTRAINT [FK_tblContentProperty_tblContent2]
GO

The foreign key constraint basically says that values in the foreign key column [ContentLink] of table [tblContentProperty] will refer to the primary key column [pkID] of table [tblContent]. So, it looks like the crux of the problem is that the job is attempting to delete rows in [tblContent] for which there are corresponding referring rows in [tblContentProperty].

You could try isolating the offending [tblContentProperty] records by doing a sql profiler trace and seeing which [pkID] values are being used to identify the rows to be deleted when the SqlException is happening. You could also try taking a look at the definition of the ListOwnedContentAssetReferences() method in EPiServer.DataAccess.ContentListDB to be clear about the how the collection of ContentReference instances is being retreived.

Hello Jeff,

Thanks for your reply. The problem has been resolved a while ago, so I've problem remember how I managed to get around it :-S Maybe something about clearing items in the trash(?)

// Sven

Hi Sven,

Glad to hear you were able to resolve the issue! Lingering items in the trash makes sense. Thank you for sharing.

Hi,

I know that I'm late to the party, but I just encountered the same issue.

You can replicate the issue following these steps:

• import a page, with images
• delete the new page (move to trash then empty trash)
• import the same page again
• manually run the "Remove Unrelated Content Assets" job
• you should get the same error

From what I can tell, the problem is that we have Blobs (added in step 1) that need to be deleted (step 2), but then, the same Blobs (the same IDs) are being added again (step 3).

If I run the "Remove Unrelated Content Assets" job before step 3, everything works fine.

Would verifying if the ID is already used, be a valid solution for this? (and if it's already used either throw an error message or generate a new ID)

Any other ideas?

Thanks