Not sure what you mean by "not handle it properly", but your code looks OK. Here is a snippet from some old test code I had around, it performs an import without the wizard:

            string tbPath = @"C:\_temp\New Termbase.sdltb";
            string definitionName = "sync";

            Sdl.MultiTerm.TMO.Interop.Application mt =
                new Sdl.MultiTerm.TMO.Interop.Application();
            TermbaseRepository tr = mt.LocalRepository;
            tr.Connect("", "");
            tr.Termbases.Add(tbPath, "Name", "description");
            Termbase tb = tr.Termbases[tbPath];

            tb.ImportDefinitions[definitionName].ProcessImport(MtTaskType.mtScript, "German", "English");

            tb.Close();
            mt.LocalRepository.Disconnect();

But... you may have found a bug in the MultiTerm API, because it does not merge. If I run the same definition (called "sync" in my setup) in theUI, it properly merges entries. Through the API it does add them as new. You may be out of luck here, I can't see a bugfix for that being high priority.

Not sure what you mean by "not handle it properly", but your code looks OK. Here is a snippet from some old test code I had around, it performs an import without the wizard:

            string tbPath = @"C:\_temp\New Termbase.sdltb";
            string definitionName = "sync";

            Sdl.MultiTerm.TMO.Interop.Application mt =
                new Sdl.MultiTerm.TMO.Interop.Application();
            TermbaseRepository tr = mt.LocalRepository;
            tr.Connect("", "");
            tr.Termbases.Add(tbPath, "Name", "description");
            Termbase tb = tr.Termbases[tbPath];

            tb.ImportDefinitions[definitionName].ProcessImport(MtTaskType.mtScript, "German", "English");

            tb.Close();
            mt.LocalRepository.Disconnect();

But... you may have found a bug in the MultiTerm API, because it does not merge. If I run the same definition (called "sync" in my setup) in theUI, it properly merges entries. Through the API it does add them as new. You may be out of luck here, I can't see a bugfix for that being high priority.

thanks fo you precious time !

Sorry, your code is nothing new

and

(have tried this time again minutes ago) makes/changes nothing

Regards

ah.. no bugs, all the time.

You may well know when you see it carefully , I have 3 times duplicates (all of them)

it came from different process

it is not perfct but it shows "some" positive result

Did you understand this part?

Gerhard Kordmann said:

But... you may have found a bug in the MultiTerm API, because it does not merge. If I run the same definition (called "sync" in my setup) in theUI, it properly merges entries. Through the API it does add them as new. You may be out of luck here, I can't see a bugfix for that being high priority.

Gerhard is the developer of the Glossary Converter which correctly handles merging.  He said if you just use the API it may not merge correctly.  So he had to deal with this by writing his own code to handle it properly.

I also agree a fix for this is very unlikely because the focus is on Cloud Terminology at the moment.  So your solution will have to be that you write the code to handle this correctly yourself.

If you see my first screenshot, you will know that I have executed "3" times(some of them are "9" times becuase it is caseInsensitive).

I guess that is more than what he said.

And, the code lacks "Import" parts, I guess.

where do I put "my Temrs.mtf.xml" file ? or myXMLelements codes ?

The import part is where it says "ProcessImport" :-) Create a copy of the "synchronize on term" import definition, and put the mtf.xml there, as the input file. You can also do this programmatically; it involves exporting the definition and fiddling with the XML. A bit messy, but doable. Since the ProcessImport does not seem to work properly, though, it's not worth digging into this here.

Exactly. I played with termbase export/import and other manipulation about 2 years ago, but found the entire Multiterm API so incredibly buggy and incomplete and not properly documented that I lost interest.

(plus, I don't work anymore on the project which involved so much fiddling with termbases, so I don't care anymore if the poor people working on the project now die from manual clicking or not...)

That crippled Multiterm creates/exports XMLs with totally different content that what it expects to be loaded/imported... task types for ProcessImport don't work as expected and documented... awful and unusable stuff... :(

thanks

that's good enough

appreciated !!

Hi Gerhard - do you remember whether the bug only affects the "Merge" operation via the API, or whether I can't sync at all via the API? As far as I understand / remember it's only via the "Synchronize on Entry Number" option that we can force MultiTerm to make incoming entry numbers survive (instead of MultiTerm renumbering / creating new ones for incoming imported entries) ... I am asking before we start spending quite some time in developing an API driven import script ...

Our customer demand / story is to automate the following: we export Coreon repository data into mtf format, assign integers for the entries (MultiTerm only allows integers for entry IDs ...), inject  CLinks to link entries to each other, then import via API script into MultiTerm sdltb local file - but for this I need the entry numbers to survive.

A workaround for us would be to create an index/language, say, "Coreon ID" that holds the Coreon IDs, and we link via TLink, but then another index / language shows up in the sdltb file (a bit ugly from a UX point of view). Therefore, I'd prefer the first option ...

Best

Michael