Are you using a source control application? If not, I suspect that may be at the heart of your problem. Everytime you open a RH project the author is updating files behind the scenes and a lock is put on them whilst they are editing. If you are then backing up to a shared location, those files could be copied over changes made by the other authors. If you want to insist on using this approach you will have to look long and hard at which authors are allowed to update files like the TOC, Index, XPJ etc whilst others are using the project. You'll also need control over what files are backed up to the network and by whom. If this sounds like a nightmare to police, a source control application is designed specifically to make instances like this easy peasy.
Read the RoboColum(n).
No. We are not using a source control application. We have discussed this but the Powers That Be aren't ready to make that change for us. However, when I open the project file, I am working locally, and the original author is no longer working on the project. We make sure that this is the case by communicating amongst ourselves before opening any projects.
In this case, I know the other author was not in the project the same time as I was. So, that still leaves me with the question about why the project closes unexpectedly. Again, we have many other projects and this is the only one with this particular problem. Anyone have additional ideas?
1 person found this helpful
Obviously this particular project has issues. But you knew that already.
First try locating and clobbering the .CPD file.
If that fails, see if you have a ProjectName.HHP file. If you do, try opening the project using that file.
Are ANY of you able to open it up? Is the only backup on the Network and now it's possibly corrupt as well? If so, perhaps you can coax your LAN Administrators to restore it from a day or two (or however long ago you feel it is worthwhile) where it works again.
Short of that, the only other option I can think of is to create a new project and begin importing content from the errant project.
Helpful and Handy Links
OK. I "clobbered" (i.e., deleted) the CPD file, then reopened the project by opening the .xpj file. Now my project opens but it was missing most of the topics. However, I was able to fix that by importing them. So now things appear to be working fine after a bit of reassembly. I will have our other writers to make sure they are able to open the project without trouble. I am hopeful. Thanks to you and Colum for your prompt replies!
Underpinning RH is an Access database and that creates an LDB file while you are using it. That gets deleted when you close the project. Even if it does not, Access will create a new one on reopening so it should not affect anything when working locally.
You say you are putting zip files on the network. We have done that without issue by zipping the project from machine 1, adding YYMMDD to the zip name and putting the zip on the network. Next author trashes or renames the last copy they worked on and then takes that zip and extracts it. Works as sweet as can be. It might be worth checking after extracting a zip to a different machine that there is no LDB before you open the project.
As longer as you only have have one person working on it and strictly observe the procedure, that should be sufficient.
See www.grainge.org for RoboHelp and Authoring tips