This, at least to me, is very bizarre. I have a report that displays the
"MicrosoftAccess has encountered a problemand needs to close" whenever I
run it first. However, if I run another report before I run that one, it
works fine. I haven't a clue as to where to begin looking or what to look
for. The record source for the report is a table. Has anyone seen anything
like this before and if so, how do I fix it?
Thanks,
RandyM
This is a hideous problem.
Don't try to do a cause and effect analysis because having "Microsoft
is sorry" crashes are totally illogical. I generally have the problem
when developing and not in production. Otherwise, I'd be out of
business.
If you added a new report, the old report would probably start working
and the new one would bomb. It's really frustrating to try to apply a
logical troubleshooting process to this kind of problem. There *IS*
no logic to it.
If this were my problem, I'd do all sorts of vodoo steps that I've
become accustomed to. They include creating a new .mdb and copying
all objects from old to new. Make sure all objects copy across
because there may not be a warning. Copy any missing objects from a
backup version of the .mdb. Then make sure that the VBA references
are set in the new file the same as the old file. If you have custom
properties in the old .mdb they will have to be recreated in the new
one. Once you have done all of this, you need to comple the VBA code
and then compact and repair the new .mdb. Every step along the way is
painful but it is possible to automate the proces.
I've found that as the size of an .mdb grows, so does the risk of
crashes. So keep an eye on the size and compact and repair
regularly. If it continues to grow anyway, then do the process in the
last paragraph.
By the way, Compact and Repair often reports that the file you were
just in isn't a valid file! It will often forget what file it's
working with and will display the "Microsoft is sorry" crash. It's
possible to create a shortcut in your send to folder that will send
your .mdb file to Access with the /repair switch. That works much
more reliably than the built in command.
I feel your pain.
Duane
