Forum Discussion
This was actually happening in 11.2 version of TestExecute.
I updated to 12.10.590 and it is continuing.
One thing of note... TestComplete is still a 32-bit application. So, if you are attempting to access Excel on a machine that has the 64-bit version of Excel on it, that COULD be your problem, or at least part of it.
I do agree that it sounds like your DDT.ExcelDriver, perhaps with the close driver method. Are you verifying that the driver you are attempting to close is non-null? That's one "hiccup" I ran into in the past using DDT, especially if I'm creating the driver across script units and so on.. it's easy to lose track and attempt to use or close a driver that may already be closed. Check your script calls and make sure that each CloseDriver call actually corresponds properly to an open driver... I've actually encapsulated such a check in a little wrapper extension I created that checks for the non-null existance of a driver before attempting the close. I've attached it in case you want to try it.
- chicks8 years agoRegular Contributor
Hi Robert, After I changed drivers the problem still occurs. Does that not mean that it is not the DDT driver? Although I suppose it could be the same problem with the other excel driver as well. The problem occurs on both a 32 bit OS and a 64 bit OS.
Thanks, Curt
- tristaanogre8 years agoEsteemed Contributor
It could still be the DDT driver. It sounds like you are "stepping" on a memory location that should not be stepped on... attempting to close a DDT driver that has already been de-allocated for some reason could easily do that.
If you can throw together a quick sample of what you are running into, perhaps not your full project, and toss it over this way, I can see if I can help debug.
- chicks8 years agoRegular Contributor
I'd appreciate it but it does not seem to be happening everywhere just on 2 of 3 platforms here and not with all scripts. Smartbear support has been unable to duplicate the issue. Though I can't tell if they have looked at the windows crash file I've sent them.....
I like the corrupted memory location theory as it seems as if the problem "built up" originally happening only 1 in 10 days and now happening consistently with some scripts. So more of a "leaky tire" problem, then a "tire fell off" problem.
I have restarted / rebooted the box but that does not seem to affect the issue.
Let me try to throw together a general outline of what I'm' doing to see if you have any comments on the driver handling..
Related Content
- 12 years ago
- 8 years ago
- 10 months ago