Lack of error message

  • Thread starter Thread starter Adam
  • Start date Start date
A

Adam

I have been building a fairly substantial Access 2K application, and just as
I am nearing the end of my coding, I have noticed a worrying new type of
behaviour.

A couple of times recently, when I have written code that doesn't work,
Access doesn't give me an error message. The code just stops executing.
Obviously, this makes it much harder to debug.

Has anyone seen anything like this before? Any suggestions for what to do
about it?

Many thanks
 
Does your code alter the Access 'Error Trapping' property at
any time? That's the one set manually in VBA
Editor|Tools|Options|General Tab.

If your code is breaking how you want just with zero
messages then I'm stumped.

Back up and a decompile is worth a try.

It is also possible that even though the code is wrong it
doesn't actually trigger an error event.
 
Your project is partially corrupt.

Compact the database. Then close Access, and make a backup copy of the MDB
file. Open a command problem, and decompile it by entering something like.
It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"
 
Many thanks for the suggestion.

I've tried decompiling the database, but it didn't solve the problem. BTW,
should I be worried that the file size increased after decompiling? I
thought it was supposed to make files smaller.

Should I be seriously worried about database corruption at this stage? Apart
from the problem I described with a lack of error message, I haven't noticed
anything else behaving badly.

Many thanks

Adam
 
Decompiling may increase the size of the db, until you compact again.

Presumably you have already checked your Error Trapping setting?
From a code window: Tools | Options | General | Error Trapping.
 
I have also observed situations where Access 2K stops issuing error
messages, after opening a form with a timer and continuing even after
closing that form (Access 2K SP3, Windows 2000 SP4). This is another reason
to avoid timer forms, but sometimes they are useful for synchronization
where form events may not be not available. Access seems to get stuck in a
mode where everything behaves as expected, except that Access fails to
display the normal messages. For example, when a required field is omitted
in a form, or a combo box has a bad value with limit to list turned on,
Access displays no message but will not save the record. Or if a query is
created with an error (such as unknown field, or too complex, or ambiguous
joins), the datasheet cannot be displayed (consistent with the error), but
no error message is actually displayed. Access continues in this mode even
after compacting or opening a new database. Completely exiting Access and
re-opening Access restores the expected behavior and the error messages are
then displayed as usual.

Steve Jorgenson once posted a similar problem for Access 2K. As I recall he
fixed it by explicitly setting the TimerInterval to zero in the form close
event. I tried this in my situation, and it did not resolve the problem, so
I am still looking for a fix. I don't know if you have a timer form
involved, but it is strange to have the normal error messages suppressed
even after the timer form is completely closed.

- Steve
 
Well, strangely enough, I do have a timer form. It is closed by the time I
get the mysterious lack of error messages, but it sounds like that doesn't
necessarily solve the problem.

So it sounds like my timer form could be responsible.

The reason why I have a timer form is as follows:

I have a form that loads when the database starts up, which does various
things that it needs to do when a user opens the database (recording logon
information, deciding which form to show next, etc). The reason why I put
this in a timer event is that if I simply put it in the form's load event,
Access crashes. I figured that this was because Access was trying to run
code before it had finished loading the various modules I have in the
database. Giving it a few seconds to load properly before it tries to run
any code seems to solve the problem.

If you have any ideas for how to get round this without using a timer event,
I'm open to suggestions.

Otherwise it sounds like I will just have to use a different startup form
while I'm debugging, unless I'm missing anything here.

Many thanks

Adam
 
Well, you could put one or more DoWait calls prior to your setup procedures.
Or you could call the Sleep API to wait a little:

Private Declare Sub apiSleep Lib "kernel32" Alias "Sleep" (ByVal
lngMilliseconds As Long)

Or call your setup using an AutoExec macro with Run, rather than inside the
load event of a startup form.

In general, I don't think a timer form should be necessary for one-time
startup procedures.

- Steve

Well, strangely enough, I do have a timer form. It is closed by the time I
get the mysterious lack of error messages, but it sounds like that doesn't
necessarily solve the problem.
....

If you have any ideas for how to get round this without using a timer event,
I'm open to suggestions.

....
Click to expand...

....
 
Thanks for the suggestions, Steve.

Actually, now I'm not so sure that the timer form has anything to do with
this. I've just done the experiment of re-inserting the original bug into my
code (which, happily, I did manage to track down and fix in the end despite
the lack of error message) and opening up the database without opening the
form with the timer event. Even after restarting my computer, this didn't
make any difference: the code just stopped when it got to the bug. I even
deleted the form from the database, and the results were the same.

So, I really can't see how the timer event could be causing this problem.
Any other ideas?

BTW, forgive my ignorance, but what is a DoWait call? I've not heard of this
before and can't seem to find it in the help files.

Many thanks

Adam
 
Thanks for the suggestions, Steve.

Actually, now I'm not so sure that the timer form has anything to do with
this. I've just done the experiment of re-inserting the original bug into my
code (which, happily, I did manage to track down and fix in the end despite
the lack of error message) and opening up the database without opening the
form with the timer event.
Click to expand...

Are you saying you fixed a bug that caused the error messages to be
suppressed? I would be interested to know what it is.
BTW, forgive my ignorance, but what is a DoWait call? I've not heard of this
before and can't seem to find it in the help files.
Click to expand...

Sorry, I meant DoEvents. (DoWait resurrected from my old memories of Paradox
days, I blame it on old age and working with too many languages.)

- Steve
 
Stephen K. Young said:
Are you saying you fixed a bug that caused the error messages to be
suppressed? I would be interested to know what it is.
Click to expand...

Alas no. I fixed the bug that caused the code to stop running. I don't think
it had anything to do with the lack of error message: the cause of that is
still a mystery to me. Any more ideas?
Sorry, I meant DoEvents. (DoWait resurrected from my old memories of Paradox
days, I blame it on old age and working with too many languages.)
Click to expand...

Thanks, I'll give it a try, although I must say I don't hold out a great
deal of hope.

Adam
 
If the problem is that the code stops mid stream and then will continue on
without error if you hit F5, the problem isn't that there is an error. I've
notice this in access 2k and xp. The problem is caused when you compile and
save the code with breakpoints in the procedures. When you remove the
breakpoints, access "remembers" that there is a breakpoint at that line and
stops execution at that point. The solution is to remove the breakpoints,
compile (you may have to add a return in the code so it allows you to
compile), and save. The problem dissapears.

Schmuckenheimer
Better late than never
 
Back
Top