I work with many FrameMaker books and files on a large network. Some chapter files in several different folders have suddenly stopped opening. A .lck file is created in the folder. The hourglass spins and FrameMaker says "Not Responding." No other error messages. Have to force FrameMaker to shut down and delete the .lck file.
This doesn't affect all files in the same folder, or even in the same book. It seems random.
If I copy these files to my desktop, they open fine. If I then File > Save As to a different folder on the same network, they open fine (aside from the broken reference links).
So I am aware this is a network issue, rather than an FM issue. But because this seems to affect only FM files, I am hoping for some idea how to troubleshoot what component of my files are being affected.
So far, I have done the following:
1. Opened the copy in different folder. Deleted all content from body and master pages. Saved back to the original folder. Will not open.
2. Opened the copy in different folder. Copied/pasted all content into a new file of same name and template, in the original folder. Opens fine.
Number 2 is a workaround, but very time-consuming, especially when there are numerous cross-refs and graphic imports to reestablish.
What else could I look at to pinpoint the problem and fix it for good?
Was this working fine for you before? If so, what's changed?
How long are your network path + filename operations? Sometimes long paths+filenames give issues.
All of these files were working fine. Then last week, I started having trouble with a few files in one folder. Then, it happened in another folder. All other files continued to work fine. Then a couple days ago, another folder. It just keeps hitting files randomly.
All file paths are typically about this long:
But as I implied above, other files within the same folder continue to open just fine, as do files in other folders with similar paths.
Nothing out of the ordinary happened (to our knowledge) to trigger this.
And when you cannot open a specific file, does this change? Can you open this file after a Windows restart or on the next day?
Do you have any colleagues? Can they open these problem files?
Can you ask your system administrators, whether there are any network changes?
Or anything with your antivirus software? (When you can open the files after you copy them to your desktop, this should not be the issue.)
No, there's no change after a restart or on the next day, BUT--
It appears this is a FM issue, after all. The files actually do open. However, instead of a second or less, they are taking 10-12 minutes to open. I've found the problem but not the cause:
Our FM books have standard headers and footers imported by cross-referencing paragraphs on the title page. When we create new chapter files from our template files, we overwrite those master pages to reference the new title page instead of the old template one.
In the past, for no apparent reason, sometimes the old cross-references that were overwritten show up again as unresolved. They are invisible, and can only be found in a search when viewing the master pages. We get rid of them by doing a blank "Change All," and the problem goes away.
However, in this case, the files are taking ages to open, and when they do, there is no "unresolved x-refs" error like normal. By trial and error, we found that the problem files all have these "ghost" cross-references (again, these are reappearing where they were previously overwritten). After we remove them with "Change All," the problem goes away and the files open immediately.
It is still a long process to fix this, and we don't know what causes it, but at least we know it can be repaired.
Do you have some sort of source control or CMS at play here?
No, we do not have a controlled system, we manually control all versioning of our docs.
Do I understand correctly that you are pulling information from your title page into your headers and footers by cross-referencing to the tags?
This is possibly a stupid question, but is there a reason you aren't using variables for this information instead? For example, the template at this job (and the job I had before) uses variables for the name of the document and the type of document (book title and subtitle, in our case). These are used on the cover page and are combined in the headers and footers for subsequent files.
Much easier than using xrefs, as all you have to do is import the user variables from the cover to the rest of the book instead of recreating xrefs. It will also cut down on Frame having to check the links, resolve the links and update the links when regenerating a file which, as you've discovered, can sometimes take a good long while.
The root cause of this problem may remain a mystery. But after this experience, that is probably what I am going to do going forward! Thanks for the recommendation.
To me, it sounds like these documents were originally created and maintained in Word.
I am not a Word power user, but as I recall, you cannot create your own variables, so if you want to have headers and footers that reference text in the document, you have to have them in a specific paragraph style that is cross-referenced from the header or footer.
It's possible that whoever created your Frame documents simply continued doing the same thing in Frame that they were accustomed to doing in Word. It does work, but it's not the optimal solution.
Typically, FM updates all cross-references whenever you open a file. To update a cross-reference to another file, FM has to open the other file as well. If a file on a network drive has numerous cross-references to other files, there can be a significant delay in checking all the cross-references.
If you think this processing may explain the delay you are seeing, you can turn off automatic updating:
1. Bring up the Update References dialog box with Edit > Update References.
2. From the Commands pull-down menu in the upper right corner of the dialog box, select Suppress Automatic Updating
You can update references at any time by checking appropriate options in the dialog box.
Lynne, thank you for the recommendation. Since the cross-ref problem appears to lie in the headers/footers, I am going to follow linsims's advice and replace them in the template with variables.