• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

Server Busy error after pulling from version control

New Here ,
Sep 27, 2017 Sep 27, 2017

Copy link to clipboard

Copied

I have a project maintained in version control via SharePoint that I need to pull down into my now-updated RoboHelp 2017. I'll get all the way through setting up my local path and have the files pulled down. However, once I click the .xpj file, it acts like it's going to open and hits me with a "Server busy, switch to busy program to activate and close it."

When you try to do so, though, it only brings up the start menu and doesn't actually take you to a program to close. Any time you click away, it brings you back. Eventually, I have to open Task Manager to kill RoboHelp.

I did already try this registry fix on another computer (I have two and am receiving the same error on both): Msscci with RoboHelp – michal.Log

No dice. I also tried these fixes on the chance they worked: Server Busy error when launching or using Lightroom on Windows

No dice there, either. I have also uninstalled and reinstalled using fresh packages for RoboHelp and SQL Compact Server. Winmerge is up to date. I do not have TFS but I do have Visual Studios 2010 for Office.

Anyone have any ideas? Thank you!

Full error text: "This action cannot be completed because the other program is busy. Choose 'Switch To' to activate the busy program and correct the problem."

Views

658

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 03, 2017 Oct 03, 2017

Copy link to clipboard

Copied

I have seen this error in the past (long time ago) but not in connection with RoboHelp. As far as I can recall, a reboot fixed it.


See www.grainge.org for RoboHelp and Authoring information

@petergrainge

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Oct 03, 2017 Oct 03, 2017

Copy link to clipboard

Copied

I'd have to check with my lead who actually fixed the issue, but I think part of it was tied to ridiculously long file names. She spent the weekend redoing file names and breaking the context-sensitive help (which our application doesn't use anyways).

Thanks!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 03, 2017 Oct 03, 2017

Copy link to clipboard

Copied

Interesting. It would be useful if you could confirm that.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Oct 04, 2017 Oct 04, 2017

Copy link to clipboard

Copied

Here was her full response:

"It was a problem internal to the project, but because of the upgrade it was more ‘sensitive’ somehow… aka the long file names. We have been getting away with it for quite some time, but it has been a best practice in both RH and SP to avoid using layers and layers of folders. You and I never changed it due to the old context sensitive help, otherwise it would have been one of the first things to fix when inheriting the project.

Specific answer… I took the project out of version control, moved the files around in the Project Manager so that there were several fewer layers of folders (which shortens the file path), rebuilt the TOC so that those links reflected the shorter paths, and put it back into version control. Can’t be exactly sure why that worked, but I used exactly the same location and permissions, so it can’t be the ‘permissions’ answer from the help desk guy. He was right that SP was throwing an error, though."

Hopefully this helps someone in the future!

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Oct 05, 2017 Oct 05, 2017

Copy link to clipboard

Copied

LATEST

Thank you. Another reason to avoid long path names rather than layers of folders. Layers are OK provided the overall length is kept in mind.

What is SP?


See www.grainge.org for RoboHelp and Authoring information

@petergrainge

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
RoboHelp Documentation
Download Adobe RoboHelp