Problems with editing DCR for picklist used in Tag GUI

We are currently experiencing problems with one of our dcrs that is used to create a picklist for Tag GUI (Metadata screen).

We cannot edit the dcr or view its properties. If we try to edit the dcr, an error message appears, saying "No workarea found". We have had no problems in editing the dcr a few months ago, and it has NOT been updated since.

When we make a copy of the same dcr via Edit/Copy menu, we are able to edit and view the properties. This is very strange as the new dcr is a direct copy of the corrupted one.

When we deleted the corrupted dcr from Workarea and Staging, we then created a new dcr via the File/New Form Entry menu, and entered some text. BUT when we tried to save it under the same name as the corrupted dcr, an error appeared, saying "Save was unsuccessful. Check the path or contact your TeamSite administrator." We then saved the new dcr to a different filename - it was successful.

Here is my question: where else does Teamsite keep track of filenames? How do we retrieve the old filename back to non-corrupted state? We need to keep the filename as status quo.

Find more posts tagged with

Comments

Ambuj

We are currently experiencing problems with one of our dcrs that is used to create a picklist for Tag GUI (Metadata screen).

We cannot edit the dcr or view its properties. If we try to edit the dcr, an error message appears, saying "No workarea found". We have had no problems in editing the dcr a few months ago, and it has NOT been updated since.

When we make a copy of the same dcr via Edit/Copy menu, we are able to edit and view the properties. This is very strange as the new dcr is a direct copy of the corrupted one.

When we deleted the corrupted dcr from Workarea and Staging, we then created a new dcr via the File/New Form Entry menu, and entered some text. BUT when we tried to save it under the same name as the corrupted dcr, an error appeared, saying "Save was unsuccessful. Check the path or contact your TeamSite administrator." We then saved the new dcr to a different filename - it was successful.

Here is my question: where else does Teamsite keep track of filenames? How do we retrieve the old filename back to non-corrupted state? We need to keep the filename as status quo.

I will suggest you to contact Interwoven Support in this case.

Adam Stoller

We are currently experiencing problems with one of our dcrs that is used to create a picklist for Tag GUI (Metadata screen).

We cannot edit the dcr or view its properties. If we try to edit the dcr, an error message appears, saying "No workarea found". We have had no problems in editing the dcr a few months ago, and it has NOT been updated since.

When we make a copy of the same dcr via Edit/Copy menu, we are able to edit and view the properties. This is very strange as the new dcr is a direct copy of the corrupted one.

When we deleted the corrupted dcr from Workarea and Staging, we then created a new dcr via the File/New Form Entry menu, and entered some text. BUT when we tried to save it under the same name as the corrupted dcr, an error appeared, saying "Save was unsuccessful. Check the path or contact your TeamSite administrator." We then saved the new dcr to a different filename - it was successful.

Here is my question: where else does Teamsite keep track of filenames? How do we retrieve the old filename back to non-corrupted state? We need to keep the filename as status quo.

The files, and their metadata, are stored within the backing store / Interwoven File System (IFS) - but you don't want to be trodding through there directly.

It probably would have been more helpful to understand how the file was corrupted - was the XML messed up? Was there a BOM inserted into it? Was the EA that indicates it is a DCR of a particular type removed or munged? etc.

Without knowing how it's difficult to suggest a way to fix it.

If you seem to be having problems with other files being corrupted too - you should probably run iwfsck - though you should also open a case with IWOV support to make sure what flags they believe you should use for running the command...