Access errors that I don't understand

  • Thread starter Thread starter louise
  • Start date Start date
L

louise

Re Access 2003

I'm writing to this group because I really don't know where
to post.

I have hired someone who states he Access Certified. I have
used him several years ago without problems. This time I
have asked him to change some reports in an existing
database and a few other similar things.

I keep having problems with his database. He seems to do
what I request but then when I go to run reports, I
frequently get debug errors. I have complained and received
the following response

"It seems that Access is stuck in going into Break mode.
This is a common bug in the Access Application. The fix is
to compile the code and Compact and Repair the file. "

Is this a "common bug" in the Access Application? Does his
comment make sense?

TIA

Louise
 
While ACCESS at times may "remember" breakpoints that are put in the code
while a developer is debugging an application, it's not a common situation.
For those infrequent situations, I usually comment out the line of code
where the breakpoint is being remembered (may have to comment out more than
one line if a compiler error occurs from leaving out that one line),
compact/repair and compile the database, then close the database, then open
it again and uncomment out the line of code and compile again. Another way
is to decompile the database by using the "decompile" switch for starting
ACCESS.

However, a more likely situation would be one of these two things:
1) The VBE's options is set to "Break on all errors" instead of "Break
on all unhandled errors".
2) The code where the "break" occurs has no error handler to trap an
error.

Very hard to say what the real cause is because we have no idea of the code
that is running when the "break" occurs, etc.
 
louise said:
Re Access 2003

I keep having problems with his database. He seems to do what I request
but then when I go to run reports, I frequently get debug errors. I have
complained and received the following response

"It seems that Access is stuck in going into Break mode. This is a common
bug in the Access Application. The fix is to compile the code and Compact
and Repair the file. "

Is this a "common bug" in the Access Application? Does his comment make
sense?
Click to expand...

It's so common that in 15 years of developing in Access I've never seen it.
Sounds like a bit of a cop-out to me, perhaps his skills are more slanted
towards tables/queries/reports than actual coding. Any developer worth his
salt wouldn't leave a deployed app in an uncompiled state IMHO.

Regards,
Keith.
www.keithwilby.com
 
To me, it sounds like his code is not fully tested. What you are describing
is not at all normal nor is it a failing of Access. A well written Access
application will almost never go into break mode. A competent developer puts
error handling routines in every routine that provides the user with
information on what caused the error and what action to take. For example,
my error routines help the user and me. It tells the user exactly what error
occurred and in which procedure. This makes it easy for me to know where to
go to fix it.

In most cases, the only errors the user should see, other than incorrect or
incomplete data entry, are when a technical problem occurs that is beyond the
control of the Access developer. For example, a lost network connection,
database corruption, etc.

As to going into break mode, this is controlled by the developer. There is
an option in Access to allow the developer to determine when to break. It
may be that option is not correctly set. The default is Break on All Errors.
This will defeat programmed error handling. It should be set to Break on
Unhandled Errors.
 
Klatuu said:
To me, it sounds like his code is not fully tested. What you are describing
is not at all normal nor is it a failing of Access. A well written Access
application will almost never go into break mode. A competent developer puts
error handling routines in every routine that provides the user with
information on what caused the error and what action to take. For example,
my error routines help the user and me. It tells the user exactly what error
occurred and in which procedure. This makes it easy for me to know where to
go to fix it.

In most cases, the only errors the user should see, other than incorrect or
incomplete data entry, are when a technical problem occurs that is beyond the
control of the Access developer. For example, a lost network connection,
database corruption, etc.

As to going into break mode, this is controlled by the developer. There is
an option in Access to allow the developer to determine when to break. It
may be that option is not correctly set. The default is Break on All Errors.
This will defeat programmed error handling. It should be set to Break on
Unhandled Errors.
Click to expand...
Thanks everyone. I think next time we need work done on the
database, someone else will be doing it :-)

Louise
 
Back
Top