• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 433 subscribers
  • Views 1196 views
  • Users 0 members are here
Options
Related

MultiTerm not updating

Willem Dubelaar

Good morning Paul,

I noticed in your response so Skye that the current version for MultiTerm should be: SDL MultiTerm 2017 - 14.1.2471.5.

When I look in "About SDL MultiTerm" of my version of MultiTerm, I get: SDL MultiTerm 2017 SR1 - 14.1.2441.0

When I press "Check for Updates", I get the following messages:

Failed to get archive directory listing
Failed to load update data file

After that, I can actually load my .sdltb and edit it.

When I go to my account on sldtrados.com, the only setup file available for download is SDLMultiTermDeskTop2017_SR1_2441.exe, dated 2017-07-25. As recently as 2018-01-01, I downloaded that file again and reinstalled MultiTerm, but it did not update anything, the version is still 14.1.2441.0.

So, my question is: Where can I get version 14.1.2471.5, please?

Best regards,
Rate translation
×
Suggest better translation
×
Moderator UI
×
  • Get AI Suggestion
Parents
  • 0
    Hello

    With the error messages you are receiving when trying to update, would suggest one or more files have become corrupted in the update folder.

    Could you try the following fix (modify the registry and add the missing user interface language.
    gateway.sdl.com/.../communityknowledge

    Then you should be able to run the update option.

    Alternatively you can run the updates manually
    gateway.sdl.com/.../communityknowledge
    via our FTP server (details at the bottom of the article.

    Please let me know if this fixed the issue for you.

    Lydia Simplicio | RWS Group

    _______
    Design your own training!
    You've done the courses and still need to go a little further, or still not clear? 
    Tell us what you need in our Community Solutions Hub

  • 0 in reply to Lydia Simplicio
    Good morning Steven,

    Eventually, it worked. I first tried to solution suggested through the first link. Though, the solution related to Studio and not to MultiTerm. For Studio, the UserInterfaceLanguage value is set to de-DE and there it works (for Studio) without any problems. So, instead, I have added the value (en-US) under MultiTerm14, where it did not exist at all. I logged off and logged back on, in order to have the registry reread, but it still did not work. Or perhaps it did, but I failed to check under "About". However, if it had worked, I should not have got the warnings. Then, I downloaded the *.msp files and installed those. It updated to the latest version, but I had to manually disable the warnings. That means, of course, that I will miss the next update.

    One thing comes to mind, as to why this might happen. I run a 64 bits system and if, when installing new 32 bits software, I am given the option of selecting the installation directory, I always do so and then choose a dedicated directory on my D drive. This, so as to spread the load and reserve the C drive as much as possible for actual 64 bits software. Could that be the reason? Could it be hard-coded somewhere that the update procedure is looking in C:\Program Files (x86)\, instead of where the software actually lives? If so, either the procedure must be recoded to look for the actual installation directory, or it must be recoded to remove the option to select the installation directory. These are just my thoughts, but I am by no means an expert in such matters.

    Many thanks,

    Willem Dubelaar
Reply
  • 0 in reply to Lydia Simplicio
    Good morning Steven,

    Eventually, it worked. I first tried to solution suggested through the first link. Though, the solution related to Studio and not to MultiTerm. For Studio, the UserInterfaceLanguage value is set to de-DE and there it works (for Studio) without any problems. So, instead, I have added the value (en-US) under MultiTerm14, where it did not exist at all. I logged off and logged back on, in order to have the registry reread, but it still did not work. Or perhaps it did, but I failed to check under "About". However, if it had worked, I should not have got the warnings. Then, I downloaded the *.msp files and installed those. It updated to the latest version, but I had to manually disable the warnings. That means, of course, that I will miss the next update.

    One thing comes to mind, as to why this might happen. I run a 64 bits system and if, when installing new 32 bits software, I am given the option of selecting the installation directory, I always do so and then choose a dedicated directory on my D drive. This, so as to spread the load and reserve the C drive as much as possible for actual 64 bits software. Could that be the reason? Could it be hard-coded somewhere that the update procedure is looking in C:\Program Files (x86)\, instead of where the software actually lives? If so, either the procedure must be recoded to look for the actual installation directory, or it must be recoded to remove the option to select the installation directory. These are just my thoughts, but I am by no means an expert in such matters.

    Many thanks,

    Willem Dubelaar
Children
No Data