M
Mark Andrews
I have newly developed code in an Access 2002 app that frequently causes a
GPF and could not be resolved with compact/repair or decompile.
The code is a loop to output multiple reports to PDF format and uses a
number of APIs to update the INI file of a third party PDF printer and check
the printer queue. The GPF doesn't occur handling any specific report and
crashes anywhere between 1 and 100 reports. Prolific use of debug statements
revealed the crash always happened during a particular function call. I was
expecting a problem from an API or perhaps repeated manipulation of the
Application.Printer object but this particular function has no API calls and
consists only of 20 or so If.. Then statements.
My next step was to put several debug statements within the function to see
if there was a specific line that caused the crash... and guess what..? No
more crashes..!! I put the code on a continuous loop but no, it just
wouldn't crash again. I've deleted the debug statements but all is still OK.
I should be pleased, right? Well I would be if I could some idea of why it
happened and how it got fixed.
I've read that code compilation has many complex levels - has inserting a
new line of code at the right place somehow removed an obscure problem at a
low level?
If Microsoft are listening I did the debug tests on a copy of the DB and
still have the original for demonstrating the GPF. My development PC has Win
XP Pro SP1 and I'm obviously running retail Access. Interesting thing is the
GPF also occurs when the app is deployed as a runtime version on a clean
Win2000 SP3 test machine. (MDAC2.7, Jet4SP5.)
If anyone has experienced a similar anomaly I'd be really grateful to hear
any reason/solution. Right now I don't have confidence deploying this new
version of our app.
Thanks in advance for any suggestions
Mark Andrews
GPF and could not be resolved with compact/repair or decompile.
The code is a loop to output multiple reports to PDF format and uses a
number of APIs to update the INI file of a third party PDF printer and check
the printer queue. The GPF doesn't occur handling any specific report and
crashes anywhere between 1 and 100 reports. Prolific use of debug statements
revealed the crash always happened during a particular function call. I was
expecting a problem from an API or perhaps repeated manipulation of the
Application.Printer object but this particular function has no API calls and
consists only of 20 or so If.. Then statements.
My next step was to put several debug statements within the function to see
if there was a specific line that caused the crash... and guess what..? No
more crashes..!! I put the code on a continuous loop but no, it just
wouldn't crash again. I've deleted the debug statements but all is still OK.
I should be pleased, right? Well I would be if I could some idea of why it
happened and how it got fixed.
I've read that code compilation has many complex levels - has inserting a
new line of code at the right place somehow removed an obscure problem at a
low level?
If Microsoft are listening I did the debug tests on a copy of the DB and
still have the original for demonstrating the GPF. My development PC has Win
XP Pro SP1 and I'm obviously running retail Access. Interesting thing is the
GPF also occurs when the app is deployed as a runtime version on a clean
Win2000 SP3 test machine. (MDAC2.7, Jet4SP5.)
If anyone has experienced a similar anomaly I'd be really grateful to hear
any reason/solution. Right now I don't have confidence deploying this new
version of our app.
Thanks in advance for any suggestions
Mark Andrews