Detecting language please wait for.......
I have just updated SDL MultiTerm 2019 to version 188.8.131.52976 and SDLTrados Studio 2019 SR1 to version 184.108.40.206768.
Now, when I try to add a new term to Multiterm from inside the editor window, the following error message appears:
...and you guessed it correctly, the new term is not added to the termbase.
This has thrown a wrench into my productivity. I am in the middle of a demanding medical project and I cannot even add a new term.
I am really tired of these half-baked updates being pushed onto paying customers and breaking the product with which we work on a daily basis.
I can't reproduce this problem, it's working fine for me.
Have you tried a Windows Repair on MultiTerm and Studio?
All the best,
I have the same problem after moving to a new computer, where the location of the termbase changed. I can see my entries after changing the locaiton, but I cannot add anything as I am gettnig the error code: object reference not set to an instance of an object.
I suspect the termbase editor is still looking in D:/ and not in C:/
Termbase location may not play any role for the file-based Multiterm. I would suppose user rights being the culprit here. Why do you store anything on C:?
My new laptop only has a C drive... The termbase search knows where the termbase is now, but the termbase viewer insists there is no termbase, hence no addition possible.
I assume, you already have reorganized the termbase? Have you also tried to repair it in Access? Did you try to reset Multiterm (like Studio, described here: https://gateway.sdl.com/apex/communityknowledge?articleName=000001414)?If you have problems within Studio, reset it too.If all does not help: export the TB to XML, save the definition and recreate the TB.
Your laptop can have as many drives as you wish. Simply create a new partition for data there and never store anything along with the OS on C.But you seem to be referring to the TB viewer in Studio? It is obvious, that it does NOT find the TB - you need to tell Studio, where the TB is. When the path changes, no program is able to follow that automatically.
This all sounds a bit complicated - I will first fnish my pending projects ...
Hi Pavel Tsvetkov
I was able to reproduce this, but if you update your Studio as well (CU 3), this will not occur anymore.
I thought Studio had updated itself, but will check that. Thank you! And I discovered I should have a 500 GB D drive after all, just cannot find it ;).
What do you mean with "updated itself"? It has of course updated all program files. But your files are not program files. Imagine, you give Studio your home address in Chicago. So Studio will remember that. When you move to San Francisco, Studio will not know that, unless you tell it - of how do you imagine shall it know about your moving?
Of course I had to tell Studio where my new termbase was. Otherwise it would not be able to find it for the search. However, after the Studio update today and after initialising my D-disk (the supplier had forgotten to add the disk when they prepared it), my termbase is working again as it should and I can also add entries.. NOt sure what exactly did the trick - the D-disk or the update, but it is working. Thank you!
On my end, the problem was solved by repairing both Mutiterm and Studio, and restarting the computer. Now, I still consider this a problem introduced by SDL, as both Multiterm and Studio had been updated when they asked for it, and all steps were followed through, but I still ran into problems
You should either fix your update packages or your update procedure, including instructions on what should follow what, if needed.
Just saying: this is a huge waste of everybody's time, including yours.
Hi Pavel Tsvetkov
It is sometimes an unavoidable symptom when updating software that something already on the PC setup may trigger some sort of malfunction/incompatibility that means it doesn't work as it should do.
This doesn't only happen with Studio, it happens with other Windows-based software too. The most frequent reason for a software malfunction I find is a large Windows update. That's what Windows Repair was designed to resolve so as far as I'm concerned, it's an unavoidable occurrence from the various software developers' perspective. They cannot know precisely what everyone's individual setup is going to be composed of.
It happens to me with Microsoft Office software too. Office has its own two-level repair facility that it is useful to run now and then.
Thank you, Ali!