nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Error:Call to sci_FindFSEByName() when editing DCR

skbaker

I recently had a user report to me that when he tries to edit a DCR, he gets a pop-up window stating:

TeamSite FileEdit
Error: Call to sci_FindFSEByName() returned with an error.

and he is unable to edit the DCR. I am also unable to edit it, and I have Admin authority on the server.

There are two clues to this behavior... one is that I have recently changed the datacapture.cfg files for most of our templates, and that may correspond with the fact that he is having troubles now. The other is that the behavior is not consistent -- he does not get this problem on all DCRs, and no other users have this problem (yet!).
Any ideas?

Find more posts tagged with

Comments

Gerard

I've seen this error before when the name of the DCR is changed and the generated file still references the old file name (see File Properties on the generated file which Primary DCR it tries to load).

Hope this helps, Gerard.

skbaker

Thanks for the hint, Gerard. You were right. When I looked at the properties for the problematic DCRs, I saw that the "Primary DCR" listed did not match the name of the DCR I was actually looking at. When I renamed the DCR back to the original name, I was able to edit it, but when I changed it back again to the "new" name, it once again failed.

Now the real question is... why isn't the "primary DCR" changed when you change the name of the DCR? That seems like terrible behavior, becuase it basically means you can never rename your DCRs!

james1

For better or for worse, the association between a file generated from a DCR and the source DCR is established at file generation time as an EA on the generated file. It is a one-way association; the generated file knows what DCR generated it, but the DCR does not know what files it has generated.

So, renaming the generated file will maintain the association, but renaming the DCR will not.

-- James

Adam Stoller

In TeamSite 5.5.2 on W2K - I recreated the situation, but I seem to get a somewhat better error message:
-------------------------
TeamSite : FileEdit
Error: Invalid dcr: \default\...\data\dcrname
-------------------------
(full path in actual error message)

I can think of ways to work around this - to track when an asset such as a DCR has been renamed - but it would probably incur a fair amount of overhead on the TeamSite server and reduce the overall performance therein.

--fish
(Interwoven, Curriculum Development)

skbaker

I appreciate the reply, James, but I'm not sure I'm stating my case clearly. The generated file itself is not in this picture at all. At no time am I attempting to open or edit (or view properties for) the generated file. I am dealing entirely with a DCR. When I rename a DCR, then view the properties of the DCR, the "primary DCR" value is not changed to reflect the name of the new DCR. That means that even if I never generate a file from a DCR, but I rename the DCR, it renders itself uneditable forever.

Is that considered acceptable or normal behavior?

Adam Stoller

There shouldn't be a PrimaryDCR property on the DCR - the DCR should contain TeamSite/Templating/DCR/Type - which unless you change the category or datatype of the DCR should not have changed by simply renaming the DCR file itself.

--fish
(Interwoven, Curriculum Development)

FileReportDoc.txt

james1

DCR's do not have a property (EA) named "primary DCR". Files that are generated from DCR's do. DCR's are the files that live in your workarea under /templatedata/[category]/[type]/data.

-- James

skbaker

I agree that it seems odd that I'm seeing a Primary DCR attribute for a DCR, but I swear that's what I see.

I'm attaching a screenshot that shows my directory structure (see that I am indeed looking under the data directory), as well as the file properties window showing the properties for the DCR in question.

The DCR being shown here was originally named "LeftNavigation.xml" by the user and then the user changed it to "hu_leftnavigation.lspl" (the extension is part of our naming convention). I also see this behavior for another DCR which was originally named "ICND" then changed to "ICND.html". My user has kinda weird naming patterns Smiley Happy

By the way, I'm using TS 5.0.1 on NT.
--Sandra

Adam Stoller

It looks like someone might have put some "magic" into the PT (LeftNav_Generate.tpl) or is using a workflow with an externaltask or some such that's explicitly adding these EA's that traditionally only go onto the generated file, onto the DCR itself (intentional? or accident?)

In either case - your choice is to either edit the EA's on that file to correct for the renaming, or delete those EA's as they generally aren't expected to be placed on the DCR -- and figure out how they are getting created there in the first place.

--fish
(Interwoven, Curriculum Development)