Access VBA crashes silently
Cruachan
corrupted VBA environment, but I can't seem to get a handle on what's
gone wrong. Any pointers would be appreciated.
The system has Office XP (2002) with Office SP3 installed running on a
new installation of XP with SP2 applied.
Everything initially ran fine, but after the my client had been running
the application for few days it started crashing with 'Access has
encountered an error and has to close' but no further details.
Stepping through the code revealed that the system could crash at a
couple of points (there are probably others) -
CreateObject("ADODB.application")
and
Kill <some filename>
In both cases the debugger would step into the line of code and then
stop. Interesting in the debugger the system didn't produce an error,
just silently stop running. This was not a hang - the system is
still responsive - it just drops out of running any code at that
point.
To confirm I created a small sample database with one form and a button
linked to the lines of code
MsgBox "Before Kill"
Kill "c:\test.txt"
MsgBox "After Kill"
This time the database ran both in and outside the debugger, but never
displayed the second message in either case - i.e. it is silently
crashing at the kill statement (the file is not removed). I can run
the database across the network on another machine and it all works
fine, so it isn't Access itself which is corrupted.
A comparison of the VBA references reveals no differences from a
similar machine where the system is still working.
The only changes that have happened between the application being
installed, when it worked correctly, and now is that a number of MS
hotfixes have been applied by MS Update, and the client has installed
another small application put together by someone in-house. This other
application appears to have been written in VB6, and the suspicion is
that this installation (using a VB6 created install we believe) has
corrupted the VBA environment. However removing the other application
and reinstalling our application does not have any effect. Indeed
we've gone so far as to unregister all dlls in the other applications
setup.lst file (except the ole dll) and ensure that all it's copies of
any files it installed have been removed.
Interesting there are another couple of boxes which are running our
application where the VB6 application was installed first, and these
appear to work fine. Also our application didn't stop working until a
day or two after the VB6 application was installed, but that may be
because no reboot was applied before then.
I've searched usenet and MS for an answer, but without an error message
it's difficult to find anything. Any help would be much appreciated.
Kevin
Norman Yuan
problem, but I tend to think it is most likely is code error problem in
Access VBA.
For example the code:
CreateObject("ADODB.Application")
You also motioned in following code snippet
MsgBox "Before Kill"
Kill "c:\test.txt"
MsgBox "After Kill"
the second Message Box does not shown when the Kill... runs into error, thus
you think Access VBA was corrupted. No, it is normal behaviour of Access.
You need add error handling in VBA code, like this:
Private Sub MyProc()
On Error Goto ErrExit
MsgBox "Before Kill"
Kill "c:\test.txt"
MsgBox "After Kill"
Exit Sub
ErrExit
MsgBox "Cannot delete: " & Err.Description
End Sub
Now, if Kill... runs into error (wrong file name, for example), Access will
show "Cannot delete:..." message, instead of silently stop. It is very basic
for Access VBA code to have error handling code.
In this example, if the second Msgbox does not show, it is clear indication
that the code is wrong (not handling inevitable error), not the Access VBA
corrupted. Also, the Access app running file sometimes does not mean no code
error, it is more than likely that the testing is not thorough enough. I'd
re-examine the code again
If it is not your typo, then it is definitely wrong. There is not
Application object in ADODB library.
"Cruachan" <g...@slovakrail.com> wrote in message
news:1111777899....@z14g2000cwz.googlegroups.com...
Cruachan
Norman Yuan wrote:
>
> Private Sub MyProc()
>
> On Error Goto ErrExit
>
> MsgBox "Before Kill"
> Kill "c:\test.txt"
> MsgBox "After Kill"
>
> Exit Sub
>
> ErrExit
> MsgBox "Cannot delete: " & Err.Description
> End Sub
>
> Now, if Kill... runs into error (wrong file name, for example),
Access will
> show "Cannot delete:..." message, instead of silently stop. It is
very basic
> for Access VBA code to have error handling code.
>
> In this example, if the second Msgbox does not show, it is clear
indication
> that the code is wrong (not handling inevitable error), not the
Access VBA
> corrupted. Also, the Access app running file sometimes does not mean
no code
> error, it is more than likely that the testing is not thorough
enough. I'd
> re-examine the code again
>
>
Sorry, maybe I shouldn't have just written down test code from memory.
The kill example is from a scratch test app I knocked up just to
confirm it wasn't our application. In our application the Kill
statement we traced the debugger to is properly surrounded by exception
processing - and checks for file exists - before executing (and it
still silently crashes). In the test app I just made sure I had a
C:\test.txt file there before running. As I said I can run the same db
across the network on another pc where it works fine and deletes the
file correctly. On the box with the problem it silently dies.
Same goes for CreateObject. Our application dies when trying to create
an ADODB object, but the test application also dies silently when
trying to open word. In this case I just used the button wizard to
place a button to open word - and it silently fails at CreateObject.
Again running the exact same database on another machine across the
network works fine.
Kevin
Cruachan
problem - we eventualy traced it down to Kaspersky Anti-Virus software
installed on the machine which by default blocks VBA calls to the OS