"Probability score": 0.7

"Question improvement suggestion": Please provide more details about the steps you took before encountering the error, and any recent changes to your system or software. Also, it would be helpful to know the exact version of Trados Studio and Glossary Converter you are using.

"In the meantime, based on the information you have provided, here is a suggested answer to your question:"

Hello,

From the error message you provided, it seems like the Glossary Converter is having trouble handling the large Excel file. This could be due to a limitation in the software or a memory issue.

Here are a few suggestions that might help:

Step 1: Ensure you are using the latest version of Glossary Converter. If not, please update it.

Step 2: Try to close all other applications while running the Glossary Converter to free up system resources.

Step 3: Check if there are any updates available for your Trados Studio software. If there are, please install them.

Step 4: If the issue persists, you might want to consider splitting your Excel file into smaller parts, as you have done before. Although this is not an ideal solution, it seems to work as a workaround.

Step 5: If none of the above steps work, you might want to consider using the beta version of the Glossary Converter that contains a fix for this bug, as mentioned in the context. You can find it at cerebus.de/glossaryconverter/beta/index.html.

I hope this answer addressed your question. If not, please reject the answer, add the question improvement suggestion information, and click the RWS Community AI checkbox on the right to try again.

RWS Community AI

I am sorry, but I already tried all of your suggestions. That leads me also to another question or rather another request to be able to merge Multiple Termbases into just one (of course provided that they have the same structure as in this case), as depending on the Merge feature in Glossary Converter is not really convenient at all, especially when you keep receiving such error messages when trying to just convert 100 K rows only from Excel. I believe there should be a way to have a multiterm native merging tool. 

Thanks a lot and I do appreciate it. 

Sameh Ragab

 Sameh Elsharkawy 

Perhaps you're overlooking a more fundamental limitation.  Your import seems to fail at around 60k entries, so a little over the 50k that works when you split the file.  You are probably aware that MultiTerm is based on MS Access and this has a 2 GB file size limit.  The linked Microsoft article states this:

"Scalability    An Access file can have a maximum size of 2 gigabytes (GB). Although 2GB is a substantial amount of text data, it may be insufficient for some applications, particularly applications that store attachments in database records. If you separate the data and the logic, your application can accommodate more data. If you expect that users will store a large volume of data, you might consider using more than one Access data file."

If we come back to your situation and do a quick back of a fag packet calculation based on the following:

• Each term entry includes one image.

• The average image size is (and you may not have images that take this care):

  • 25 KB if compressed (e.g. optimised PNG/JPG).

  • 100 KB or more if uncompressed or high resolution.

• Each non-image term entry (text only) occupies:

  • Roughly 1–2 KB, depending on field complexity.

That gets you around 200 Mb for the term metadata and 2.5 Gb for the images... so well over the limit.  Given you said the two halves worked just fine perhaps size is your issue here?

 Sameh Elsharkawy 

Perhaps you're overlooking a more fundamental limitation.  Your import seems to fail at around 60k entries, so a little over the 50k that works when you split the file.  You are probably aware that MultiTerm is based on MS Access and this has a 2 GB file size limit.  The linked Microsoft article states this:

"Scalability    An Access file can have a maximum size of 2 gigabytes (GB). Although 2GB is a substantial amount of text data, it may be insufficient for some applications, particularly applications that store attachments in database records. If you separate the data and the logic, your application can accommodate more data. If you expect that users will store a large volume of data, you might consider using more than one Access data file."

If we come back to your situation and do a quick back of a fag packet calculation based on the following:

• Each term entry includes one image.

• The average image size is (and you may not have images that take this care):

  • 25 KB if compressed (e.g. optimised PNG/JPG).

  • 100 KB or more if uncompressed or high resolution.

• Each non-image term entry (text only) occupies:

  • Roughly 1–2 KB, depending on field complexity.

That gets you around 200 Mb for the term metadata and 2.5 Gb for the images... so well over the limit.  Given you said the two halves worked just fine perhaps size is your issue here?

Dear Paul,

Thank you for your detailed response and the insightful analysis regarding the Microsoft Access limitations impacting MultiTerm’s performance. Your point about the 2 GB file size cap is well-taken, and it indeed sheds light on the issue I’ve been grappling with. However, I’d like to pivot the conversation toward a broader discussion of the systemic constraints in MultiTerm’s architecture and propose that RWS consider more robust solutions to address these longstanding pain points. The issues I’ve encountered are not merely isolated inconveniences but symptomatic of deeper structural limitations that hinder productivity and scalability in modern translation workflows.

Firstly, the dependency on Microsoft Access as the backbone of MultiTerm’s termbase architecture is increasingly untenable. While Access may have been a pragmatic choice in the past, its limitations are now a significant bottleneck, particularly for creative and media-rich termbases. For instance, technical glossaries, medical device terminologies, or sports databases—like the one I’m working on—often require embedded media such as images or diagrams to provide context. The 2 GB size cap, coupled with Access’s inability to efficiently handle large datasets, stifles the ability to build comprehensive termbases that include such assets. Moreover, even for text-only Excel files exceeding 200,000 rows, MultiTerm struggles to complete conversions reliably. This scalability issue is not just a minor inconvenience; it fundamentally undermines the ability to manage large-scale, enterprise-level terminology projects. I strongly urge RWS to explore a modern database engine—perhaps SQLite or PostgreSQL—that can handle larger datasets and multimedia content without imposing such rigid constraints.

Secondly, I’ve attempted workarounds like editing the Windows Registry to increase the MaxLocksPerFile value, which occasionally mitigates issues with smaller datasets. However, this is a band-aid solution at best. For termbases approaching millions of entries, as is common in my work, the Glossary Converter consistently fails, even with optimized settings. This points to a deeper issue in MultiTerm’s data processing logic, which appears ill-equipped to manage high-volume imports. The fact that splitting a 100,000-row Excel file into two 50,000-row files resolves the issue only underscores the inefficiency of the current system. A professional-grade terminology management tool should not require such manual intervention to function effectively. RWS must prioritize enhancing the Glossary Converter’s robustness to support massive datasets natively, without forcing users to resort to fragmented workflows.

Thirdly, even when a large termbase is successfully created, its integration into the Trados Studio Editor introduces significant performance degradation. As translators navigate segments, the editor’s responsiveness slows considerably, and in some cases, it crashes entirely. This is particularly frustrating in high-pressure translation workflows where speed and reliability are paramount. The root cause appears to be MultiTerm’s inefficient querying mechanism, which struggles to retrieve terms from large termbases in real time. This not only disrupts productivity but also erodes confidence in the tool’s suitability for enterprise environments. A more optimized indexing and retrieval system is desperately needed to ensure seamless integration with Trados Studio.

Finally, I’d like to revisit our discussions from Ukraine about the potential for RWS to adopt a search technology akin to DTSearch. The indexing capabilities of DTSearch could revolutionize not only termbase management but also the handling of large Translation Memories (TMs). By leveraging advanced indexing, RWS could enable near-instantaneous term lookups and TM searches, even for datasets in the millions of entries. This would be a game-changer for translators, eliminating the performance bottlenecks that currently plague MultiTerm and Trados Studio. While I understand that rearchitecting MultiTerm and Trados to incorporate such technology is no small feat, the competitive landscape demands it. Translators need tools that scale effortlessly with the growing complexity of global projects, and RWS is uniquely positioned to lead this transformation.

In closing, I deeply appreciate your expertise and the support you’ve provided. However, the issues I’ve outlined—Microsoft Access’s limitations, Glossary Converter’s scalability problems, performance degradation in Trados Studio, and the untapped potential of advanced indexing—represent critical barriers to achieving faster, more productive workflows. I urge RWS to treat these as strategic priorities and invest in modernizing MultiTerm’s architecture. By doing so, RWS can empower translators to tackle ambitious projects with confidence and efficiency.

Thank you again for your time and consideration. I look forward to your thoughts and, hopefully, a roadmap for addressing these challenges.

Best regards,

Sincerely,

Sameh Ragab

I even tried to merge all the 3 termbases split into 1 master termbase, but immediately Glossary Converter crashed. 

Exception of type 'System.OutOfMemoryException' was thrown.

Source: mscorlib
   at System.String.CtorCharPtrStartLength(Char* ptr, Int32 startIndex, Int32 length)
   at System.Runtime.InteropServices.Marshal.PtrToStringUni(IntPtr ptr, Int32 len)
   at System.Data.OleDb.ColumnBinding.Value_ByRefWSTR()
   at System.Data.OleDb.ColumnBinding.Value()
   at System.Data.OleDb.OleDbDataReader.GetValues(Object[] values)
   at System.Data.ProviderBase.DataReaderContainer.CommonLanguageSubsetDataReader.GetValues(Object[] values)
   at System.Data.ProviderBase.SchemaMapping.LoadDataRow()
   at System.Data.Common.DataAdapter.FillLoadDataRow(SchemaMapping mapping)
   at System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue)
   at System.Data.Common.DataAdapter.Fill(DataSet dataSet, String srcTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
   at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Filters.SdlTbReader.GetTable(String selectCommand)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Filters.SdlTbReader.Initialise(String path)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Core.FieldReader.Read(List`1 inputFilters, List`1 inputPaths)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Workflow.Converter.Convert(List`1 inputFilters, List`1 inputPaths, IFilter outputFilter)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Workflow.FileHandler.HandleMultipleFiles(List`1 files)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Workflow.FileHandler.ProcessFiles(List`1 files)
Program version 6.4.9138.36048

Windows version: Windows 10, Build 19045, 64 bit (English (United States))

.net versions:
v2.0.50727  2.0.50727.4927  SP2
v3.0  3.0.30729.4926  SP2
v3.5  3.5.30729.4926  SP1
Client  4.8.09037
Full  4.8.09037
Client  4.0.0.0


 MultiTerm version: MultiTerm 18.0.0.0



<Settings version="4">
  <Fields>
    <Field>
      <FieldName>Player ID</FieldName>
      <FieldType>EntryField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>JS Player ID</FieldName>
      <FieldType>EntryField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Sport</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>National Team</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>National Team Number</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Club</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Club Number</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Weight (kg)</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Height (cm)</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Position</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Preferred Foot</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Age</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Date of Birth</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Nationality</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Text</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>Media</FieldName>
      <FieldType>TermField</FieldType>
      <FieldContent>Media</FieldContent>
      <Ignore>false</Ignore>
    </Field>
    <Field>
      <FieldName>English</FieldName>
      <FieldType>Language</FieldType>
      <FieldContent>Language</FieldContent>
      <Ignore>false</Ignore>
      <LanguageCode>en</LanguageCode>
    </Field>
    <Field>
      <FieldName>Arabic</FieldName>
      <FieldType>Language</FieldType>
      <FieldContent>Language</FieldContent>
      <Ignore>false</Ignore>
      <LanguageCode>ar</LanguageCode>
    </Field>
  </Fields>
  <Windows>
    <Settings>
      <Left>524</Left>
      <Top>204</Top>
      <Width>660</Width>
      <Height>599</Height>
    </Settings>
    <MainWindow>
      <Left>2290</Left>
      <Top>152</Top>
      <Width>390</Width>
      <Height>390</Height>
    </MainWindow>
    <ContentType>
      <Left>1092</Left>
      <Top>439</Top>
      <Width>400</Width>
      <Height>245</Height>
    </ContentType>
    <ChooseLanguage>
      <Left>961</Left>
      <Top>176</Top>
      <Width>400</Width>
      <Height>240</Height>
    </ChooseLanguage>
    <PicklistValues>
      <Left>1235</Left>
      <Top>480</Top>
      <Width>400</Width>
      <Height>220</Height>
    </PicklistValues>
  </Windows>
  <AlwaysShowFieldsDialog>false</AlwaysShowFieldsDialog>
  <CheckForUpdates>true</CheckForUpdates>
  <PlaySound>false</PlaySound>
  <PerformanceMode>false</PerformanceMode>
  <XpathAllowRedundantFields>false</XpathAllowRedundantFields>
  <PlainExcelMode>false</PlainExcelMode>
  <ExcelHistory>false</ExcelHistory>
  <ExcelTags>true</ExcelTags>
  <CollapseExcelFields>true</CollapseExcelFields>
  <RawMode>false</RawMode>
  <DetectWebLinks>true</DetectWebLinks>
  <MergeFiles>true</MergeFiles>
  <SkipReorgTermbase>false</SkipReorgTermbase>
  <UseTermbaseTemplate>false</UseTermbaseTemplate>
  <UseMasterTermbase>true</UseMasterTermbase>
  <MergeLanguages>true</MergeLanguages>
  <MergeSubLanguages>false</MergeSubLanguages>
  <ExportEntryNumber>false</ExportEntryNumber>
  <MasterTermbase>H:\VIP Translation Resources\All Terminology\Kooora\kooora-Player_Names_Termbase-Final.sdltb</MasterTermbase>
  <MergeField></MergeField>
  <TermbaseTemplate></TermbaseTemplate>
  <Synonyms>
    <Type>OneLine</Type>
    <Column></Column>
    <Repeat>false</Repeat>
    <Separator>|</Separator>
  </Synonyms>
  <MultiFieldMode>MultipleFields</MultiFieldMode>
  <DefaultOutputFilter>MultiTerm Termbase</DefaultOutputFilter>
  <UiLocale>en</UiLocale>
  <UiTheme>Default</UiTheme>
  <SettingsPage>TabMerging</SettingsPage>
  <EmptyOutput>false</EmptyOutput>
  <IgnoreUnknownFields>false</IgnoreUnknownFields>
  <CreateEmptyFields>false</CreateEmptyFields>
  <WriteDocType>true</WriteDocType>
  <VerifyXml>true</VerifyXml>
  <SkipVerify>false</SkipVerify>
  <CreationUser>glossaryconverter</CreationUser>
  <TbCopyright></TbCopyright>
  <TbDescription></TbDescription>
  <UseContentFilter>false</UseContentFilter>
  <RegexContentFilter>false</RegexContentFilter>
  <ContentFilterText></ContentFilterText>
  <Tbx>
    <XcsSupport>false</XcsSupport>
    <XcsAsk>false</XcsAsk>
    <V2Basic>false</V2Basic>
    <Dialect>Core</Dialect>
    <ResolveNote>true</ResolveNote>
    <MappingFile></MappingFile>
    <Tbx3Mode>Pragmatic</Tbx3Mode>
    <UseMappingFile>false</UseMappingFile>
  </Tbx>
  <TbxHistory>false</TbxHistory>
  <BilingualSourceLanguage></BilingualSourceLanguage>
  <BilingualTargetLanguage></BilingualTargetLanguage>
  <ForceBilingual>false</ForceBilingual>
  <ForceBilingualHeader>false</ForceBilingualHeader>
  <OutputChangeFolder>false</OutputChangeFolder>
  <OutputFolder></OutputFolder>
  <SilentOverwrite>false</SilentOverwrite>
  <OpenOutput>false</OpenOutput>
  <UseLibreOffice>false</UseLibreOffice>
  <UseMultiterm>true</UseMultiterm>
  <UseStudio>true</UseStudio>
  <SortMode>Source</SortMode>
  <ResolveXmlEntities>false</ResolveXmlEntities>
  <SdltmWaitMinutes>20</SdltmWaitMinutes>
  <ExportTradosTmx>false</ExportTradosTmx>
  <RemoveEmptyColumns>false</RemoveEmptyColumns>
  <PicklistSeparator>,</PicklistSeparator>
  <MultiFieldSeparator>~</MultiFieldSeparator>
</Settings>
in: 
	H:\VIP Translation Resources\All Terminology\Kooora\kooora-Player_Names_Termbase-Final.sdltb
	H:\VIP Translation Resources\All Terminology\Kooora\kooora-Player_Names_Termbase-1.sdltb
	H:\VIP Translation Resources\All Terminology\Kooora\kooora-Player_Names_Termbase-2.sdltb
	H:\VIP Translation Resources\All Terminology\Kooora\kooora-Player_Names_Termbase-3.sdltb
out: H:\VIP Translation Resources\All Terminology\Kooora\kooora-Player_Names_Termbase-Final.output_merged.sdltb

Conversion start: 5/18/2025 5:00:12 PM
****  There was an error creating the output file.
System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.String.CtorCharPtrStartLength(Char* ptr, Int32 startIndex, Int32 length)
   at System.Runtime.InteropServices.Marshal.PtrToStringUni(IntPtr ptr, Int32 len)
   at System.Data.OleDb.ColumnBinding.Value_ByRefWSTR()
   at System.Data.OleDb.ColumnBinding.Value()
   at System.Data.OleDb.OleDbDataReader.GetValues(Object[] values)
   at System.Data.ProviderBase.DataReaderContainer.CommonLanguageSubsetDataReader.GetValues(Object[] values)
   at System.Data.ProviderBase.SchemaMapping.LoadDataRow()
   at System.Data.Common.DataAdapter.FillLoadDataRow(SchemaMapping mapping)
   at System.Data.Common.DataAdapter.FillFromReader(DataSet dataset, DataTable datatable, String srcTable, DataReaderContainer dataReader, Int32 startRecord, Int32 maxRecords, DataColumn parentChapterColumn, Object parentChapterValue)
   at System.Data.Common.DataAdapter.Fill(DataSet dataSet, String srcTable, IDataReader dataReader, Int32 startRecord, Int32 maxRecords)
   at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataSet dataSet)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Filters.SdlTbReader.GetTable(String selectCommand)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Filters.SdlTbReader.Initialise(String path)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Core.FieldReader.Read(List`1 inputFilters, List`1 inputPaths)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Workflow.Converter.Convert(List`1 inputFilters, List`1 inputPaths, IFilter outputFilter)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Workflow.FileHandler.HandleMultipleFiles(List`1 files)
   at Sdl.MultiTerm.Tools.GlossaryConverter.Workflow.FileHandler.ProcessFiles(List`1 files)

Sameh Elsharkawy 

Sameh Elsharkawy said:

I even tried to merge all the 3 termbases split into 1 master termbase, but immediately Glossary Converter crashed. 

Why would this be a surprise after everything we've just discussed?

Sameh Elsharkawy said:

I urge RWS to treat these as strategic priorities and invest in modernizing MultiTerm’s architecture.

You have several good options, depending on your needs and resources:

• Adopt Cloud Terminology, which represents the future of terminology management at RWS.  It’s actively being developed and offers a scalable, modern solution that integrates well across the platform.
• Consider using GroupShare, which leverages a SQL Server database rather than Access.  It’s a robust option for managing larger termbases and is already well-suited to enterprise-scale scenarios, such as the one you're working with.
• Develop your own custom terminology solution, especially if you have specific requirements or want to explore alternative technologies.  With recent improvements to the Studio architecture, this is now much more feasible.

You may have noticed that MultiTerm has been decoupled from Trados Studio in recent releases.  It now operates as a plugin, which opens the door for 3rd-party terminology tools to integrate seamlessly with Studio via the same APIs.  This provides a lot of flexibility - for example, you could build a plugin using MongoDB or another high-performance database designed to handle large datasets.

It’s unlikely that MultiTerm’s architecture will be overhauled to support newer, high capacity database types, but the good news is that you’re no longer limited to this access-based solution as a user.  The ecosystem is evolving to offer more scalable, modern alternatives, especially for users with more advanced or enterprise-level needs that the vast majority of freelance users would never need.

Sameh Elsharkawy 

Sameh Elsharkawy said:

Finally, I’d like to revisit our discussions from Ukraine about the potential for RWS to adopt a search technology akin to DTSearch. The indexing capabilities of DTSearch could revolutionize not only termbase management but also the handling of large Translation Memories (TMs). By leveraging advanced indexing, RWS could enable near-instantaneous term lookups and TM searches, even for datasets in the millions of entries. This would be a game-changer for translators, eliminating the performance bottlenecks that currently plague MultiTerm and Trados Studio.

I have a few thoughts on this one:

1. I had a couple of developers look at this when we discussed it many years ago.  DTSearch isn't really built to be used in this way and the integration would have to be a lot deeper than we have access to without it becoming more of a core product feature.  I had them waste too much time on it then, and won't do it again.
2. I don't really believe this would be a game changer.  The number of translators using the sort of resources you play with is pretty small, but even if it were not I think the way we work is changing so rapidly that working with such large datasets in the way we leverage a TM is yesterdays news.
3. I doubt that such large datasets contain a predominance of domain specific material and are more likely bloated with bitexts that an NMT solution will provide far quicker, and probably with a better quality at the first pass.

So, feel free to put it into the ideas section, but I doubt it will get any support.