Studio 2017 AutoSuggest candidates not displayed

Issue may be related to inability to add or generate AutoSuggest dictionaries.

(Attempting to add a dictionary gives error message "The AutoSuggest dictionary file could not be read," and trying to generate one fails after extracting phrases, with message "unable to open database file," details attached (hopefully).) AutoSuggest dictionaries are one of my selected AutoSuggest providers, but after excluding them, still no display of any candidates from other providers.


All settings in Studio 2017 are identical to those in Studio 2015, where everything works fine. Tried repairing the installation, reinstalling, and restarting. Looking forward to seeing AutoSuggest candidates when I start typing, but so far, nothing at all. Any help would be appreciated. Thank you. P.S. Looking forward to Regex Match Autosuggest Provider for 2017.

<SDLErrorDetails time="11/18/2016 11:46:33 AM">
  <ErrorMessage>unable to open database file</ErrorMessage>
  <Exception>
    <Type>System.Data.SQLite.SQLiteException, System.Data.SQLite, Version=1.0.103.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139</Type>
    <ResultCode>CantOpen</ResultCode>
    <ErrorCode>14</ErrorCode>
    <HelpLink />
    <Source>System.Data.SQLite</Source>
    <HResult>-2147467259</HResult>
    <StackTrace><![CDATA[   at System.Data.SQLite.SQLite3.Open(String strFilename, String vfsName, SQLiteConnectionFlags connectionFlags, SQLiteOpenFlagsEnum openFlags, Int32 maxPoolSize, Boolean usePool)
   at System.Data.SQLite.SQLiteConnection.Open()
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.DatabaseConverter.CreateBiligualPhraseFile(String path)
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.DatabaseConverter.Convert(String flatFilePath, String dbFilePath)
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.PhraseExtractionProcessor.CreatePhraseDb(DataLocation location, String dbFilePath)
   at Sdl.LanguagePlatform.TranslationMemoryTools.PhraseExtraction.PhraseExtractionProcessor.Process(String tmxFilePath, CultureInfo sourceCulture, CultureInfo targetCulture, Int32 maxIterationCount, Int32 maxTUs, String dbFilePath)
   at Sdl.TranslationStudio.Common.Jobs.PhraseExtractionJobRequest.Execute(IJobExecutionContext context)
   at Sdl.Desktop.Platform.Implementation.Services.Job.<_worker_DoWork>b__3()
   at Sdl.Desktop.Platform.Implementation.Services.Log.Resources(Object message, Action action)
   at Sdl.Desktop.Platform.Implementation.Services.Job._worker_DoWork(Object sender, DoWorkEventArgs e)
   at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)]]></StackTrace>
  </Exception>
  <Environment>
    <ProductName>SDL Trados Studio</ProductName>
    <ProductVersion>14.0.0.0</ProductVersion>
    <EntryAssemblyFileVersion>14.0.5746.0</EntryAssemblyFileVersion>
    <OperatingSystem>Microsoft Windows 10 Pro</OperatingSystem>
    <ServicePack>NULL</ServicePack>
    <OperatingSystemLanguage>1041</OperatingSystemLanguage>
    <CodePage>1252</CodePage>
    <LoggedOnUser>TEN\MMM</LoggedOnUser>
    <DotNetFrameWork>4.0.30319.42000</DotNetFrameWork>
    <ComputerName>TEN</ComputerName>
    <ConnectedToNetwork>True</ConnectedToNetwork>
    <PhysicalMemory>8388132 MB</PhysicalMemory>
  </Environment>
</SDLErrorDetails>

Parents Reply
  • Indeed, I noticed SQLite in the error details in my first post but did not feel like mucking around (as if I were qualified to muck). I suppose the file path bug will be resolved eventually, but I am glad that it is a known issue. I seem to recall similar file path bugs in previous versions of Studio that were resolved.

    A benefit of using Windows on a Mac, as you know, is that all "network" folders (used for projects and various other files, such as AS dictionaries) can be accessed in macOS and backed up by Time Machine (and other software, as needed) instead of some Windows alternative.
    I see that the Studio Migration Utility copies all project files to a local destination, but this is no good for users such as myself who prefer our existing, "network"-based file management with Studio 2015. Looks like I will be adding required project files to Studio manually instead of using the utility for that.
    Anyway, thanks again for the constructive feedback.
Children
  • Glad you managed to resolve this... thanks Jesse!

    Unknown said:
    A benefit of using Windows on a Mac, as you know, is that all "network" folders (used for projects and various other files, such as AS dictionaries) can be accessed in macOS and backed up by Time Machine (and other software, as needed) instead of some Windows alternative.

    A benefit of using something like dropbox for this is that you can use the migration utility as the folder is in effect a local one that is backed up.  I'm not familiar with Time Machine but maybe you can map your folders to one in windows somehow and achieve the same thing?  Does this article help?

    lifehacker.com/.../how-to-set-up-time-machine-to-back-up-to-a-networked-windows-or-linux-machine

    Paul Filkin | 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

  • Thank you for sharing the Dropbox suggestion and Time Machine article, Paul. Sorry for the delay in replying.

    Time Machine is convenient. However, the article you kindly mentioned seems to show how to back up to a Windows destination, not from a Windows source.

    Parallels and Fusion have made backing up virtual machines slightly easier, but unless I am mistaken, backup still involves an essentially monolithic VM file instead of individual folders within the OS. Not sure about any recent innovation in this regard. Anyway, that's one reason to keep those folders outside of Windows, unless one uses various Windows backup solutions.

    Dropbox never really appealed to me, but I admit to using CrashPlan for remote backup. (A Windows version of CrashPlan is also available, but that seems indirect, in my case.) Not a big fan of CrashPlan, but it's secure and reliable.

    Personally, I still find it interesting to mix OSes this way, despite the network file path issues. From my perspective, Windows seems like some kind of theatrical stage. If I wheel it away, so to speak, I see the folders that have been residing in macOS all along. I'm probably not the only translator who likes to tinker with things and live between worlds.

    Anyway, thank you for all of the helpful advice you have shared with the community through the years.