How to clean up after Sitecore template "Shared" setting was "packaged" and "installed" and items using this field are unaware

1
votes

we faced very specific scenario in our Sitecore enviroment. In our Sitecore we have a item, lets call it "Promotion". Promotion was using "End date" field that was shared.

On our dev instance we "unshared" the field. Which naturally triggers the background process that changes the items to use field in unshared mode. Similar process is described here: http://sitecoreblog.alexshyba.com/2011/10/changing-field-sharing-settings-in.html So then we packaged and installed change of "unsharing field" on production "master" database. As I assume during installation the background process of "updating the items" has not been triggered. Which now behaves in the way, that "unshared" field on our production master database cannot be saved. Cahnges of value after clicking save are "vanishing". I am sure they are now being saved in some language agnostic mode.

Of course simple fix for that is to "share" it back and "unshare" it again. However when we tried to do this experiment on copy of our enviroment and we noticed all the values were lost. As the items from mentioned template are heavily used, we cannot really afford loosing those values.

Any ideas?

2
sitecore
Why don't you do the exact thing you did on Dev for Production server, i mean manually change the field to 'unshare' without packaging? – Ahmed Okour
Packaging was done actually from dev to Sitecore in first place. So now we can "share" the field, which would end in erasing the values. – Paweł Forys
I suggest you contact Sitecore Support about this, it looks like a sitecore bug to me. – Ahmed Okour

2 Answers

1
votes

I would go "database digging". Sitecore stores these field values in their respective databases inside the "SharedFields", "VersionedFields" and "UnversionedFields" tables.

Assuming you shut off your Sitecore instances (this is important), you should be able to SELECT the data out of the wrong table, and INSERT it into the correct one.

(you need to look for items where FieldId matches the field you are having trouble with)

From what you've described, I don't believe Sitecore has removed any data on your production environment (yet).

1
votes

So the solution we came up to, was to use Sitecore Rocks tool. We exported all the Items containing the fields before changing the field to "Share". The query was more or less like that:

SELECT @@ID, @#Start Date#, @#End Date# FROM //*[@@templateid='{993DC54F-6724-46C3-B8D2-3EE13F15366A}']

It gave us proper values at that point, even though to items were pointing to the SharedFields table. We just simply converted the result of this query (around 9000 rows) in Excel to Sitecore Rocks update query -

UPDATE SET @#Start Date#='20120531T000000',@#End Date#='20120614T000000' FROM //*    [@@ID='{E3FD9819-3DBD-4FAA-8DEF-FEF2A6272723}'];

After prepared this migrations script, we shared the appropriate field and apply the script of 9000 updates queries through Sitecore Rocks. We need to to exactly the same on Live database. Everything went pretty smooth.

The same approach could be easily done with the database I believe, however this solution was better for us, because of non-technical reasons (security policies etc.). Anyway Sitecore Rocks rocks!