Forum Discussion

edkallen's avatar
edkallen
Occasional Contributor
7 years ago
Solved

AccessDatabaseEngine guessing wrong

When I upgraded to TestComplete 12.40 I also had to install the Access Database Engine to access the .csv files that are used to drive my scripts. However it appears that the Access Database Engine is sometimes failing to guess the correct type for the data and guessing that the data is numeric, when really it needs to guess text. In the past I set HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Jet\4.0\Engines\Text\ImportMixedType to "Text" to avoid errors, but that doesn't seem to be working any more.

 

Is there a different registry setting I should be using?

 

Thanks,

Ed

  • edkallen's avatar
    edkallen
    7 years ago

    Looks like I was off by a wee bit. The correct engine is the 'Text' engine (...\Access Connectivity Engine\Engines\Text) which defaults to 'Majority Type', not the 'Excel' engine. Changing that fixed the issue.

     

    Thanks,

    Ed

     

     

     

5 Replies

Sort By
  • edkallen's avatar
    edkallen
    Occasional Contributor
    7 years ago

    I've found the registry key that's supposed to govern the guessing for mixed types (under HKLM\SOFTWARE\Microsoft\Office\14.0\Access Connectivity Engine\Engines\Excel), but it's still not making me happy. I'm still getting a null instead of the text. For the amount of effort I'm putting in to resolve this, it's going to be quicker to write my own dumb .csv file reader with aqTextFile to read the file and aqString.GetListItem.

     

    Thanks,

    Ed

    • edkallen's avatar
      edkallen
      Occasional Contributor
      7 years ago

      Looks like I was off by a wee bit. The correct engine is the 'Text' engine (...\Access Connectivity Engine\Engines\Text) which defaults to 'Majority Type', not the 'Excel' engine. Changing that fixed the issue.

       

      Thanks,

      Ed

       

       

       

    • edkallen's avatar
      edkallen
      Occasional Contributor
      7 years ago

      Robert,

       

      Is it possible to use one schema.ini file in a centralized location to rule over many directories? Our tests are organized with the drivers and expected results in a separate directory together, so there's 100's of directories. The idea of a schema.ini file in each directory isn't terribly appealing.

       

      There's a master directory which contains the script telling which script(s) are going to be run. Would putting a schema.ini file in that directory rule over the rest of the directories also? Currently, that master script is always loaded.

       

      BTW, the registry entry on that page references the Jet Engine instead of the Database Access Engine and needs to be updated for 12.40.

       

      Thanks,

      Ed

      • tristaanogre's avatar
        tristaanogre
        Esteemed Contributor
        7 years ago

        The schema.ini needs to be in the directory in which the files it references resides.  However, one schema.ini file can contain information for multiple files.  That's as per the Microsoft link that's referenced in the article I provided.  This is a limitation, not in TC, but generally in Microsoft's CSV engine.

         

        An alternative which I have employed in the past: In the CSV file, force everything to be a string by wrapping the data element in quotes.  So, even integers are strings in the CSV file.  Then, in the automated test code, use the aqConvert methods to convert the data into the desired format.  This gives you direct control over how the data in the CSV file is used without having to depend upon operating system settings or other external files.  Even changing the registry goes out the window if you run the tests on a different machine that hasn't been altered.  What I've done in the past is create different routines to retrieve the data from the files and store them in an object variable for use elsewhere.  That way I have complete control of the data and it's formats.