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
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
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.
