I managed to solve my own problem by uninstalling RoboHelp 8, restarting, reinstalling RH8, repairing RoboSourceControl (required to fix) then opening my project from the source files on the server. This crashed RH8. But opening witout a link to the source and removing the files from source control allowed the project to open. Then putting the files back into source control seemed to fix the problem. What a round about way to recover from a program update. Beware of RoboUpdates.
I sympathise with the situation you faced and I will be sending Adobe a link to this thread.
However, I cannot agree that this is an update that people should not take. Quite the reverse. People who do not take this update will face issues requiring a project repair that will recur and recur. There are many threads testifying to the problems that were occurring and that lead to the patch being introduced.
It looks to me as if some addtional instructions are required for source controlled projects.
As soon as I can find out more, I will return to this thread. Meantime for non source controlled projects, this is one update that you really should apply. For source controlled projects, people will have to make their own decision while I try to get further input.
See www.grainge.org for RoboHelp and Authoring tips
Follow me @petergrainge
I agree with Peter. This is an important update. I can't weigh in on any RSC implications, because we don't have RSC up and running right now, but none of our writers have experienced any issues with 8.0.2. The service release seems to be doing just what it is supposed to. I would be surprised if RSC was directly involved in the issue.
Rasterdan2U, did you do things in this order:
1. Apply the service release.
2. Delete the cpd file for your project.
3. Open the project.
If you did not delete the cpd before opening the project, that might account for the problems you ran into. Because the cpd files are local to each machine, everyone would have to delete them before opening the project (the first time after applying the SR).
With a source-controlled project, the extent of the fpj damage due to the fpj bug might be worse than with a standalone project. Or at least the approach to a compromised project might be a bit different. You'd probably have to roll the entire DB back to a point before the fpj files got hammered. I don't know if there would be a more elegant way to just roll back the fpj files...Then, of course, all authors would have to revert all their files, as well.
Ugh. Makes my head hurt.
No, I did not delete anything, the update ran and restarted. There was no message that I needed to delete any files. Maybe this would be a nice instruction with the update. I'll bet most people would not know to do this. Just how would they know this is necessary. Nothing was noted in the release notes either. Only 3 lines indicating what was modified in the release.
This was a terrible waste of time at a critical moment. I will not apply any more updates unless we are having a specific problem which needs an update and only when we get a breather. Luckily we have backups.
Thanks for the feedback, I will file this away in my Robo email folder for future consideration.
Rasterdan2U, I don't know for certain that this was your issue, but it may be. We were beta testers for the service release, and I had the writers delete the cpd files as part of the process. So that part was already behind them when they applied the service release. I'm going to leave it to the Adobe experts to weigh in on whether that's really the issue, or whether something else is afoot.
What I do know is that when things get fouled up in a project, 80% of the time the CPD file is the culprit!
1 person found this helpful
And another thing to consider...
Prior to the fix, we also experienced a situation where the fpj files were compromised for quite some time before the problem visibly manifested. The problem only became apparent when the cpd file needed to be rebuilt.
Rasterdan2U, I would recommend that you take a look at the fpj files in your project to make sure that they are correct. Yes, even if your project *appears* to be complete. Without the service release in place, you are at risk of having your fpj files go bad on you. It's possible that various versions of the cpd files could be holding the project together, with varying degrees of success. Again, I don't know if this is actually the case for you, but it's something that we experienced here with at least one of our projects.
Until you do have the service release in place, you should back up a local copy of your project daily (for example, make a zip of the project folder). You might need it in the future.
Whenever I get a message about making an .fpj file writable I say NO. This prevents the fpj being incorrectly updated (becoming an empty file). I get this message in RH6.
It's probably a good idea to check the fpj in source control when you get the message, just to make sure the full file is correctly stored.
Additionally, if you check out the file from source control, then get a good version (usually a maximum of one check in back) then you don't have to jump through hoops with uninstalling/reinstalling/repairing. I think I've even done it with RH open and it just refreshes the list, although it might be more prudent to closeRH first.
Just one thing to add. Gravenstein's post said to delete the CPD after applying the patch and before opening the project. The steps on a standalone project are in Opening RH Projects on my site and they were checked with Adobe. It states there to apply the patch, open the project, repair any broken links, close the project and then delete the CPD.
See www.grainge.org for RoboHelp and Authoring tips
Follow me @petergrainge
Thanks for the input but I am not changing anything until maybe January at the earliest. I just got my project working and if it ain't broke, don't fix it. I don't have time to risk taking the project down again. If something happens that causes my project to not work, I will start with these steps. For now, I have a lot to do and 2 days of lost time makes it even worse.
Thanks again for your feedback.
I have four RH8 projects, all source controlled using VSS, and I was getting the .fpj problem after updating to 8.02.208. Unfortunately, I opened two projects before coming here to see if there was a solution. Gravenstein's suggestion of deleting the .cpd file worked a treat on the two projects I hadn't opened. However, the projects that had been opened were irreparable, so I had to get a clean copy from VSS. Everything is now back up and running, with only about half an hour lost.
Thanks for the help.
I had to pull all topics from source control.
After encountering the problem I did the following in about this sequence:
- uninstalled RH8.
- reinstalled RH8.
- installed the 8.0.1 update.
- attempted to run the project but no luck.
- performed a repair on version control.
- moved my project to a new folder for safe keeping.
- opened the project from version control to pull the entire project. (now at 509Mb/compile size 91Mb)
- attempted to open the project from version control but RH8 locked up. (nothing moving through the VPN tunnel)
- disconnected from the VPN so there would be no path to the server.
- browsed to the folder using the open command and opened the project manually.
- RH8 wanted to access version control but I told it not to and to not continue trying.
- When prompted I took the project out of version control to check for the missing part of my project(all ok now).
- Since all was ok, I reconnected to the VPN and placed the project back into version control.
- The project would open but locked up randomly, usually 15 or 20 minutes.
- Closed RH8 and renamed the .cpd file as you recommended. (shot in the dark)
- Reopened RH8 and it seems to be working now. It ran all afternoon without any problems. (thanks for that tip!)
Today it is complaining about the RSO3 service on the server. I am attempting to have someone reboot the system. The server is 3000 miles away so I can't just pop over and do it myself. I am hoping that this is an unrelated event.
I have not installed the 126.96.36.199? update. I can't afford any down time until after Christmas. This project will launch the first week of Jan. so ... if it ain't broke, i'm not fixing it.
I am wondering how it is going to handle the 992 global variables that I am about to throw at it. This is going to be interesting. If it works, it will be particularly nice for our field engineers.
Thanks for your help and interest.
Just an update, our server rebooted and there was a request to update RH8. Naturally we declined but... it may be possible that the RSO3 Middle Tier services were not started because of that update request? Anyway, our IT guy started those services and we are back in business. This may be helpful to others who are having trouble accessing projects from source control.
Now that we are back from the holidays and we managed to get a mostly accurate compile, we are having problems with the rhvariables file. I added about 1000 variables and it all works good on my system. After checking in my project, my colleague does a get all and gets an error message: "An error occured while trying to read data from the path\rhvariable.apj> <5>"
We had to cut and paste our variables using MS Access so we did not loose the first 800+ variables when the 8.0.2 killed our project. Any ideas as to how to sync these files? If we just drop a copy of the rhvariables into my folder, we get the same message. Is this because we had to modify the .cpd file? Is there some other place where the variables is located that needs to match or needs some other bit of info to work toghether?