OK, after a lot of digging around in the Umbraco DB I think I might have gotten to the bottom of this. I found there was a node in the database that was "corrupt".

In the umbracoNode table there is a column called nodeUser and on this node it was set to '4' - referencing a user ID that didn't exist in the umbracoUser table (I think they'd been deleted). This had "corrupted" the node and I think it was also what was causing the exception - Umbraco appeared to be looking up this User and not being able to find it it threw a wobbly!

I updated the nodeUser value to the ID of a user that existed and this fixed it.

Thanks for updating this, and not meaning to hijack the thread because I think your original question still stands.

With this now being exposed it would be interesting to get more information on why the cache can be corrupt, what the impact is of this (I don't perceive any impact?) and if it is capable of correcting itself.

We're noticing these buttons stating fix several times per day with regular editors working in the back-end.

I agree with Dan - it would be useful to get answers to these questions.

I've noticed one of the sites I've upgraded to 7.3.1 often reports the XML Cache as being corrupt, but have no idea how serious this is or what impact it may have. I'm sure someone must know!

I'm seeing this too, on 7.3.4, and I still haven't seen any answers to the questions:

1. What is the impact of the "Content in the cmsContentXml table... Error" if left untreated?
2. What causes this to be in an error state?
3. What does "Fix" do, and how long does it take? I tried running it, and while it didn't throw an exception, after several hours, it didn't seem to have done anything but was still running.

Following - I asked this a while ago but got no answer. We've a site go live this week on 7.3.0 which has major issues with corrupt cache and examine indexes getting out of sync very quickly.

Very concerning that a feature like this is introduced with no explanation as to what it does or why it's there!

We have a site running on 7.3.4 which we have recently upgraded from 7.1.8.

It shows to Fix Content & Media in cmsContent Table.

We got error when clicked on the "Fix" button.

Would like to know what has gone wrong & what does the button actually do?

Error Details :

Failed to retrieve data integrity status

This SqlTransaction has completed; it is no longer usable.

EXCEPTION DETAILS:

System.InvalidOperationException: This SqlTransaction has completed; it is no longer usable. STACKTRACE:

at System.Data.SqlClient.SqlTransaction.ZombieCheck() at System.Data.SqlClient.SqlTransaction.Rollback() at Umbraco.Core.Persistence.Database.CleanupTransaction() at Umbraco.Core.Persistence.Database.AbortTransaction() at Umbraco.Core.Persistence.Transaction.Dispose() at Umbraco.Core.Persistence.Repositories.ContentRepository.RebuildXmlStructures(Func2 serializer, Int32 groupSize, IEnumerable1 contentTypeIds) at Umbraco.Core.Services.ContentService.RebuildXmlStructures(Int32[] contentTypeIds) at Umbraco.Web.WebServices.XmlDataIntegrityController.FixContentXmlTable() at lambda_method(Closure , Object , Object[] ) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ActionExecutor.<>cDisplayClass10.9(Object instance, Object[] methodParameters) at System.Web.Http.Controllers.ReflectedHttpActionDescriptor.ExecuteAsync(HttpControllerContext controllerContext, IDictionary`2 arguments, CancellationToken cancellationToken) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at System.Web.Http.Controllers.ApiControllerActionInvoker.

I did some digging into this and it looks like it's checking the content services against the raw database and comparing the number of published nodes.

Unless they are equal it shows 'Fix'. Fixing will rebuild the XML stored in the database for all documents.

I'm not sure what the practical impact of it being broken is yet.

Thanks, Dan.

It still raises a few questions though...

Why does it happen? It seems to occur via normal Umbraco usage.

What bad things can happen when it's corrupt, if any?

If it is essential for the smooth running of Umbraco should it just be run automatically (say on application start or on a schedule)?

I've had this problem when adding some document types programatically. The API lets you do stuff that the rest of the system considers invalid. It doesn't cause any problem in generating from the content to the cache, but when looking at what "valid" is, such as when exporting things for a package, it blew up for me, due to a NRE too.

I've not seen that behavior doco'd anywhere, so I'm not sure what fields were not what they should've been, and don't remember how I fixed it, but thought I'd share, just in case. :)

OK, let's try to explain.

Technically, what the Xml Data Cache integrity does is:

• content: ensure that there are as many published items (as reported by ContentService) as content rows in table cmsContentXml
• media: ensure that there as as many items (as reported by MediaService) as media rows in table cmsContentXml
• member: ensure that there are as many members (as reported by MemberService) as member rows in table cmsContentXml

When it reports that there is an error for "content" and exposes the "fix" button and you click that button... the content rows in cmsContentXml are rebuilt entirely by loading each content item and serializing it again to Xml.

As the OP (Dan) noted, this may fail if, for some reason, a node cannot be serialized properly. In Dan's case, the umbracoNode table was referencing a user in umbracoUser table and that user was not existing anymore. What happens then is that the failing nodes will not be in cmsContentXml, and therefore will not be loaded into the in-memory Xml cache. In other words, they are not treated as "published".

So the consequence of an error for "content in the cmsContentXml table" is: some nodes that you think are published will not show in the in-memory Xml cache and will appear "unpublished". Whether that has a strong, or small, practical impact on your site... probably depends on your site.

Also note that, however, as long as the in-memory Xml cache has not been forcefully reloaded from database, it all lives on top of the umbraco.config file, which can contain nodes that are not in the database anymore.

What would cause such situations?

Inconsistencies in Umbraco's API, I'm afraid. In Dan's example... why would a content reference a non-existing user? Probably because, somewhere, a constraint is missing plus the API does not handle that situation properly.

Should you fix?

Would consider it a good idea on a healthy site.

But what if it fails?

If you have a lot of content, rebuilding may take time. A lot of time. Make sure it is not crashing in the background. Also, look at Umbraco's log for Exception traces that could help point you to the root of the problem.

Thinking of it, the Exception message could (and probably should) at least report the ID of the content item that is causing the Exception--so you'd know where to start from.

But unfortunately... you're entering the debugging zone, really.

It did not use to be like this!

Indeed. In the past, we all thought that the Xml cache was always consistent. Because there was no way to check. So... that integrity controller can be considered a "fail fast" approach. An error there does not mean that new issues were introduced: only, now, you know about the old issues.

Making sense?

I have been having problems with the cache integrity "fix" from version-to-version.

Our 7.3.0 build would periodically tell me content in the cmsContentXml table was in error and "fix".

Since upgrading to 7.3.8 I cannot get the "fix" to work. It cycles around for a bit and then ....Error.

I cannot find anything in the logs to indicate why this is happening.

Can anyone help, or indicate any further problem its likely to cause.

M.

Same here - I built a 7.3.0 site then upgraded to 7.36 then 7.3.8. I too cannot get around the 'fix' content issue, constantly shows the red error

Best you will get advice wise i'm guessing will be to download the source and step through it - we've done that and it was painful but still didn't find what we needed to :(

Hopefully someone will have the magic answer :)

Same here - upgraded to 7.3.8 and always get this error on cmsContentXml and fix never works. Sounds like it needs to be reported as an issue. Anyone know whether this works in 7.4.x ?

Not tried it yet on 7.4.x but not sure I want to upgrade as not overly keen with the new features. Need to work my way into 7.4 land :-)

Yea, I'm not going to venture into 7.4 until the next minor patch release....still too many bugs in 7.4.1 to consider it.

M.

I was also seeing this issue on a 7.4.2 configuration. The XML data integrity report kept saying the cmsContentXml table had errors, but running the Fix didn't change anything. There were no errors reported in the Umbraco logs while running the fix.

I was also having trouble emptying the recycle bin, so I used the following SQL statement (found here, but tweaked a little to work on 7.x) to empty the recycle bin manually:

DECLARE @nodeId int

DECLARE node_cursor CURSOR FOR 
SELECT Id
FROM umbracoNode
WHERE ParentId = -20

OPEN node_cursor;

FETCH NEXT FROM node_cursor 
INTO @nodeId;

WHILE @@FETCH_STATUS = 0
BEGIN
    print @nodeId

    delete from [dbo].cmsDocument where nodeId = @nodeId
    delete from [dbo].cmsContentXml where nodeId = @nodeId
    delete from [dbo].cmsPreviewXml where nodeId = @nodeId
    delete from [dbo].cmsPropertyData where contentNodeId = @nodeId
    delete from [dbo].cmsContentVersion where ContentId = @nodeId
    delete from [dbo].cmsContent where nodeId = @nodeId
    delete from [dbo].umbracoUser2NodePermission where nodeId = @nodeId
    delete from [dbo].umbracoNode where id = @nodeId

     FETCH NEXT FROM node_cursor 
    INTO @nodeId
END
CLOSE node_cursor;
DEALLOCATE node_cursor;

After emptying the recycle bin using this SQL statement, the XML data integrity report was no longer reporting any errors on the cmsContentXml table.

Hi Arjan

I used this SQL, I extended the table a little further, to ensure everything was eradicated. Annoyingly in my 7.3.8 build dbo.UmbracoAccess and dbo.UmbracoAccessRule seem to have foreign keys which prevent dbo.UmbracoNode from clearing down. So I set the them to cascade and the SQL completed.

I got me an empty and useable recycle bin again, but it didn't fix the cmsContentXml cache error. The fix button continues to fail too.

Martin

Hi all ... firstly note that there are many comments on here with various problems so it's a bit difficult to answer everything concisely. I'll start with a few important points:

• If you find a bug put it on the tracker with steps to reproduce and maybe even how to fix it if you know. If you don't do this, the bug will continue to exists because the details in threads like this will be lost in the abyss
• So from the above, we know there are at least 3 bugs:
  • Something about the recycle bin not being able to be emptied from @Arjan - so please if you have issue details, please put this on the tracker
  • Something that @martin has found with something to do with the umbracoAccess tables which I don't think is related to this topic but again ... please put this info on the tracker
  • A null reference exception which actually is related to the original topic here regarding serializing content - @Dan - can you please log this issue on the tracker?

Ok, on the the details of this topic, here are some facts:

• Since the dawn of time (around Umbraco version 2), the way the xml cache file is generated is based on the content found in cmsContentXml. The data in this table is populated when content is published, the content item is serialized to xml. This is how the xml gets into the cache file
• Since version 7.3, we added a dashboard (http://issues.umbraco.org/issue/U4-6673) to verify that the content in the xml file matches the content in the cmsContentXml (i.e. data integrity). This is to bubble up any existing problems... this didn't cause any of the problems
• 7.4.3 is one of the most stable versions ever released - you should upgrade now. There are 493 issues resolved since 7.3.0. Of those issues, 349 are resolved in 7.4.x! The upgrade process is seamless, 7.4 is much nicer to work with ... so not sure what you're waiting for. I would strongly advise upgrading because the chances are that your issues are fixed - or at least some causes to those issues.

Hi Shannon

Thanks for the info. I do indeed post up bugs if I think I can report it without it ending up terribly vague or unrepeatable.

As Dan mentioned, i'll hold off upgrades keeping a close eye on the bugfix list. With 7.4.x I wasn't satisfied with the build until 7.4.3. So i'm in the process of running the upgrades now.

I've upgraded our main project from 4.0.4.2 all of the way up to (currently) 7.3.4 and I suppose it's inevitable that the schema would get a little mixed up in the journey, but using the recommendations in this thread, I have a working recycle bin again! It would be difficult for me to express this as a "bug" in the schema as I have no idea how the schema changes are carried over from version to version. Short of providing you with my schema as DB backup.

The second issue I have is the fix button continually failing despite fixing the schema. I cannot generate any errors in the process failing though. Nothing appears in the logs. So i'm unsure what to do next, otherwise I would've posted it as bug.

Martin

I was getting the error "The Xml cache is corrupt. Use the Health Check data integrity dashboard to fix it" after upgrading from umbraco 7.1.8 to 7.5.4.

Clearing the recycle bin with the above SQL script fixed the issue (Fix button on the Data integrity dashboard didn't help).

is working on a reply...