Forum Discussion
Hi,
I am not sure if it make sense to you but i had the same problem with TE and even with TC. Try clearing unnecessary logs, free up some memory, and most importantly reduce the no of tests that run in the suite.
I also raised the tickets sent dumps but unfortunately the problem was not solved. Only thing that helped is reducing the number of tests that run in one go.
Regards
Osaid
Question: Are you making sure that you call DDT.CloseDriver on your Excel driver before you create another instance? I know for CSV files there's a maximum number of connections that you can have open before DDT.CSVDriver starts returning errors about being unable to open another connection.
If you're consistently having problems with opening a LOT of Excel connections, that would be where I'd start checking... basically, a rule of thumb is that, for every DDT.ExcelDriver call, you should have a corresponding DDT.CloseDriver call to close the Driver object when you're done using it. Something like:
function MyTestCase() { var xcelDriver; xcelDriver = DDT.ExcelDriver('C:\\MyDocs\\MyXcel.xlsx', 'TestSheet', true); //do some stuff DDT.CloseDriver(xcelDriver.Name); }
- chicks8 years agoRegular Contributor
Hey Robert,
I noticed with the latest set of crashes that it was failing instantly. The first thing my scripts do is use the DDT driver to fetch some global information. Prior to that TestExecute would crash after proceeding to the actual separate tests. I conclude from that that the DDT (ACE) driver did not like the combination of spreadsheet / environment.
Short Version: It looks like it crashed on the initial opening of the ddt.exceldriver before I had any chances to close it or open more drivers....
Regards, , Curt
- tristaanogre8 years agoEsteemed Contributor
Yeah... I think I'm with you on this that there is something environmental around the interface to Excel via the ACE driver... perhaps not necessarily a problem with TestComplete/TestExecute directly.
Have you tried moving the tests to a different machine with a fresh install of Excel? Also, the machine in question, is it running the 64-bit version of Office/Excel? Have you tried creating a "dummy" project to access a "dummy" excel file to see if the problem occurs there?- tristaanogre8 years agoEsteemed Contributor
Just as a note, it is for reasons like this that I built my framework (and have been convinced to maintain the structure by guys like AlexKaras) around CSV files instead of Excel. There is just something about depending upon files created within a very particular piece of software as driving the data for a test project... I like Excel, I use it... but it is limited in it's portability and you are not the first person to complain about the reliability and stability of it as a data storage for long term use. Just my $0.02... and with conversion rates these days, that might not be worth a lot. ;)
Related Content
- 12 years ago
- 8 years ago
- 10 months ago