Access 2.0 - How to debug MS Runtime errors with Acess Runtime?

Dominic Ng

unread,

Jan 22, 1997, 3:00:00 AM1/22/97

to

Hi,
I have a general question regarding errors occurring during runtime. I
developed and tested an Access application. After creating the runtime
version and distributed on the users' pcs, an error occurs in a form with
: A runtime error has occurred - you do not have permission to view this
module. After a lot of guessings and testings the error is simple - the
attached tables are not connected because the mapped drive is missing.
I would not have spent all the time if I were shown the code where it
fails.

My questions are:-
1. Is it true that the runtime envoronment would not show the code window
with the error, even though I am the owner of the database, with full
administrator capabilities?
Or is something wrong here with Acess security?

2. I am going to implement error trappings in my codes now - but are there
other good advices on how to debug a runtime error (ie user does not have
full development access)?

Thanks in advance,
Dominic
domi...@unn.unisys.com

Terri Torrez

unread,

Jan 23, 1997, 3:00:00 AM1/23/97

to

On 22 Jan 1997 15:16:23 GMT, "Dominic Ng" <domi...@unn.unisys.com>
wrote:

>My questions are:-
>1. Is it true that the runtime envoronment would not show the code window
>with the error, even though I am the owner of the database, with full
>administrator capabilities?

Yes, the Access runtime version has design functions shut off. An
error in the runtime version that isn't properly trapped will cause
the program to exit because it can't show the code window.

>2. I am going to implement error trappings in my codes now - but are there
>other good advices on how to debug a runtime error (ie user does not have
>full development access)?

The only thing you can do is debug as much as possible and set up
error handling to trap the unexpected. Consistent error handling is
important to any professional application, but, as you've no doubt
figured out, it's essential to the runtime version.

Terri Torrez
terri....@marcam.com

Tom van Stiphout

unread,

Jan 26, 1997, 3:00:00 AM1/26/97

to

"Dominic Ng" <domi...@unn.unisys.com> wrote:

>Hi,
>I have a general question regarding errors occurring during runtime. I
>developed and tested an Access application. After creating the runtime
>version and distributed on the users' pcs, an error occurs in a form with
>: A runtime error has occurred - you do not have permission to view this
>module. After a lot of guessings and testings the error is simple - the
>attached tables are not connected because the mapped drive is missing.
>I would not have spent all the time if I were shown the code where it
>fails.

>My questions are:-

>1. Is it true that the runtime envoronment would not show the code window
>with the error, even though I am the owner of the database, with full
>administrator capabilities?

>Or is something wrong here with Acess security?

>2. I am going to implement error trappings in my codes now - but are there

>other good advices on how to debug a runtime error (ie user does not have
>full development access)?

>Thanks in advance,
>Dominic
>domi...@unn.unisys.com
Hi Dominic,

The runtime environment will never show a code window, regardless of
your permissions.
Having an error handler in EVERY procedure is a great step towards
fixing the continue/reinitialize errors. Also put one in Form_Error if
you are using bound controls.
If you are using OCXes in your forms, you may need to relax
permissions on these forms.

-Tom.

Pete Cresswell

unread,

Jan 26, 1997, 3:00:00 AM1/26/97

to

>2. I am going to implement error trappings in my codes now - but are there
>other good advices on how to debug a runtime error (ie user does not have
>full development access)?

I put the following 11 lines of boilerplate in each and every
Basic routing I wrote. I've got a AutoKeys macro programmed to
do it, so the process is painless.

"debugStackPush" pushes the routine's name into an array. and
"debugStackPop" removes it from the same array once everything
has gone OK.

"bugAlert" pops an informative error window and/or writes details
of the error to an ASCII text file. It gets the name of the
routine from the array loaded by "debugStackPush".

----------------------------------------
Sub whatEver ()
debugStackPush Me.name & ": whatEver"
On Error GoTo whatEver_err

(whatever Basic code you want to write...)

debugStackPop

whatEver_xit:
On Error Resume Next
(free any pointers used by basic code...)
Exit Sub

whatEver_err:
bugAlert ""
Resume whatEver_xit
End Sub

----------------------------------------

Brad Alexander

unread,

Feb 3, 1997, 3:00:00 AM2/3/97

to

Error handling is the answer here. I have several databases with over 50 users and I had the same problems. I finally decided to have my error handling procedures record each error in a table. I then looked at the highest hitters and begin the debug process. I have now had each system up and running for over a year with out a single error. If you would like a sample of the code I used drop me a line. -- *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ Brad Alexander Ho...@vnet.net *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~ When you sit down at a table look for the fool.... If you don't see one get up, the fool is you... *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~