473,320 Members | 1,832 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

A97 closes down each time I open a particular report. Anyone know the meaning of this?

MLH
Trouble is, it doesn't happen every time. Yesterday, for example, it
happened only once and not again afterward. Some days ago, a similar
situation. Today, well - I tried 7 times straight to open the report
and each time, A97 shuts down. The seemingly hit 'n miss nature of
the error is intriguing. All I've been able to determine is that if I
allow the report to be opened from within code using this line...
DoCmd.OpenReport "rptPendingOutboundCorrespDetails"
.... it opens fine. And, each time thereafter, it opens fine. When
I experience the problem, I just open the report with a command
button that invokes that line and the problem seems to go away.
That is, I can successfully open the report by dbl-clicking it in the
database window numerous times thereafter w/o error.

Anyone ever experienced anything like this?

The error report Access writes for submission to MSoft is stored in
C:\Documents and Settings\Owner\Local Settings\Temp\weraf.tmp.dir00\
directory in a file named appcompat.txt. Reading that verbose file
does nothing to help me understand what might be happening.
Nov 13 '05 #1
9 1743

"MLH" <CR**@NorthState.net> wrote in message
news:gh********************************@4ax.com...
Trouble is, it doesn't happen every time. Yesterday, for example, it
happened only once and not again afterward. Some days ago, a similar
situation. Today, well - I tried 7 times straight to open the report
and each time, A97 shuts down. The seemingly hit 'n miss nature of
the error is intriguing. All I've been able to determine is that if I
allow the report to be opened from within code using this line...
DoCmd.OpenReport "rptPendingOutboundCorrespDetails"
... it opens fine. And, each time thereafter, it opens fine. When
I experience the problem, I just open the report with a command
button that invokes that line and the problem seems to go away.
That is, I can successfully open the report by dbl-clicking it in the
database window numerous times thereafter w/o error.

Anyone ever experienced anything like this?

The error report Access writes for submission to MSoft is stored in
C:\Documents and Settings\Owner\Local Settings\Temp\weraf.tmp.dir00\
directory in a file named appcompat.txt. Reading that verbose file
does nothing to help me understand what might be happening.


I have had this happen with a corrupted memo field.

It this is your problem, it cannot be fixed with a repair and compact. You
will need to create a new table, copy the good records; then delete the old
table.
Nov 13 '05 #2
MLH
You may have a point there, Ron. I have tried repair/compact - nothing
changed. I will select a few suspect tables (report based on a qry w/
several tables) and recreate them one-at-a-time. Will follow back up
with you on this. Thx for the suggestion.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


I have had this happen with a corrupted memo field.

It this is your problem, it cannot be fixed with a repair and compact. You
will need to create a new table, copy the good records; then delete the old
table.


Nov 13 '05 #3
MLH
To update you, Ron, it has not been readily apparent to me just where
the corruption was. But I am rebuilding selected objects that are
suspect. David Fenton commented that corruption was less likely to
lie the in the tables are more likely the report object. Problem with
the darned thing is that the error was hit 'n miss. I was unable to
reliably produce it on every run. So, it was not at all evident to me
after trying some fix whether the fix worked or otherwise. I'll feel
more confident in a few days that the problem is gone. But I'll never
know for certain which object was the problem. That really dampens
the learning experience. Unfortunate.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I have had this happen with a corrupted memo field.

It this is your problem, it cannot be fixed with a repair and compact. You
will need to create a new table, copy the good records; then delete the old
table.


Nov 13 '05 #4
MLH <CR**@NorthState.net> wrote in
news:ff********************************@4ax.com:
To update you, Ron, it has not been readily apparent to me just
where the corruption was. But I am rebuilding selected objects
that are suspect. David Fenton commented that corruption was less
likely to lie the in the tables are more likely the report object.
Problem with the darned thing is that the error was hit 'n miss. I
was unable to reliably produce it on every run. So, it was not at
all evident to me after trying some fix whether the fix worked or
otherwise. I'll feel more confident in a few days that the problem
is gone. But I'll never know for certain which object was the
problem. That really dampens the learning experience. Unfortunate.


Since you seem to have eliminated the possibilty of the corruption
being in the report object (though I don't think you really did, as
you created it in the existing MDB, and corruption of code-bearing
objects is not always related only to the code in the object itself,
since the code can have depencies in outside modules that could be
the location of the corruption -- you have to use a fresh MDB built
from objects that were newly built and can't be corrupt), I think
the corruption is likely in a lower level.

You mentioned the table first, but I think you need to look at the
intermediate level between the report and the table, and that's the
SQL that populates the report. As I suggested in another post, if
you're using a saved query, try copying its SQL directly in the
report's recordsource (or vice versa, i.e., if you're not using a
saved query, try doing so). If that doesn't help, try assigning the
recordsource in the report's OnOpen event.

But keep in mind that any functions called in your SQL could be the
source of the problem, for instance. You need to consider all the
dependencies in your report (including any subreports).

Last of all, it could be that the problem is data-related, and that
some particular datasets cause the report to crash.

You might want to experiment with removing sorting and grouping, if
the report has any, because that can be a source of problems.

Also, if you're doing anything with memo fields in the report, that
could point to memo field corruption (which would be table-level
corruption and ought to be repaired by a compact of the back end).

One last thing: I assume your data is coming from a linked table.
Try deleting the links and recreating them -- there's information
cached in those links that can become out of date and end up causing
problems. That's more an A2K problem than it is an A97 problem, but
it's theoretically possible in A97 as well.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #5

"David W. Fenton" <dX********@bway.net.invalid> wrote in message
news:Xn*********************************@216.196.9 7.142...
MLH <CR**@NorthState.net> wrote in
news:ff********************************@4ax.com:
To update you, Ron, it has not been readily apparent to me just
where the corruption was. But I am rebuilding selected objects
that are suspect. David Fenton commented that corruption was less
likely to lie the in the tables are more likely the report object.
Problem with the darned thing is that the error was hit 'n miss. I
was unable to reliably produce it on every run. So, it was not at
all evident to me after trying some fix whether the fix worked or
otherwise. I'll feel more confident in a few days that the problem
is gone. But I'll never know for certain which object was the
problem. That really dampens the learning experience. Unfortunate.


Since you seem to have eliminated the possibilty of the corruption
being in the report object (though I don't think you really did, as
you created it in the existing MDB, and corruption of code-bearing
objects is not always related only to the code in the object itself,
since the code can have depencies in outside modules that could be
the location of the corruption -- you have to use a fresh MDB built
from objects that were newly built and can't be corrupt), I think
the corruption is likely in a lower level.

You mentioned the table first, but I think you need to look at the
intermediate level between the report and the table, and that's the
SQL that populates the report. As I suggested in another post, if
you're using a saved query, try copying its SQL directly in the
report's recordsource (or vice versa, i.e., if you're not using a
saved query, try doing so). If that doesn't help, try assigning the
recordsource in the report's OnOpen event.

But keep in mind that any functions called in your SQL could be the
source of the problem, for instance. You need to consider all the
dependencies in your report (including any subreports).

Last of all, it could be that the problem is data-related, and that
some particular datasets cause the report to crash.

You might want to experiment with removing sorting and grouping, if
the report has any, because that can be a source of problems.

Also, if you're doing anything with memo fields in the report, that
could point to memo field corruption (which would be table-level
corruption and ought to be repaired by a compact of the back end).

One last thing: I assume your data is coming from a linked table.
Try deleting the links and recreating them -- there's information
cached in those links that can become out of date and end up causing
problems. That's more an A2K problem than it is an A97 problem, but
it's theoretically possible in A97 as well.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc


I would have to disagree with David about repair and compact fixing memo
field corruption in A97. I was getting memo field corruptions until I
followed advice from this group to use unbound fields to reference memo
fields in a form. The corruption appears as "ERR" in the memo field when
viewing a table view. A97 would crash as soon as I entered the record.
Repair world not fix the problem and would sometimes fail complete. A easy
check is to open the table and scroll though all the records, A97 will crash
if you have this problem.
Nov 13 '05 #6
On Wed, 14 Sep 2005 23:27:54 -0500, "David W. Fenton"
<dX********@bway.net.invalid> wrote:

David makes some good suggestions. In addition, and more generically
I'd like to say an important debugging technique is to "simplify the
problem".
In your case, you have a lot of possible sources of the problem. So
eliminate them one by one.
For example, if currently your back-end is on a server, move it local.
That eliminates all network-related issues.
If your report currently draws from a query, turn it into a maketable
query and point your report to it. That eliminates all query-related
issues.
Simplify your report by taking out grouping levels, and more and more
fields.
Etc.

Be sure you're current with all service packs. Repeat your tests on
another machine.

<clip>

Nov 13 '05 #7
Looking at this and the related thread, it seems to me you have spent a
lot of time on this problem.
I would have:
a) compiled the report's vb (if there is any) to see if any error is
reported; this should compile all your code, thus identifying any
problem in some code upon which the report depends;
b) saved the report as text and loaded it back in as text; if there's
an error in the report it should NOT reload;
c) deleted the report and recreated it (hoping the new one works);;
d) asked the access wizard to create a report using the same
recordsource as the problem report (to see if the problem occurs in
something never touched by human hand).

THEN if I had no success I might have thought about table corruption.
If I concluded there night be table corruption I would have used
SaveAsText 6 etc to get a fresh copy of the db tables.

I think this would not have taken me an eternity.

Nov 13 '05 #8
"paii, Ron" <pa**@packairinc.com> wrote in
news:Oa******************************@athenet.net:
I would have to disagree with David about repair and compact
fixing memo field corruption in A97. I was getting memo field
corruptions until I followed advice from this group to use unbound
fields to reference memo fields in a form. The corruption appears
as "ERR" in the memo field when viewing a table view. A97 would
crash as soon as I entered the record. Repair world not fix the
problem and would sometimes fail complete. A easy check is to open
the table and scroll though all the records, A97 will crash if you
have this problem.


What I wrote was misleading, I guess. No, compact doesn't *fix* the
corrupted memos, but in my experience you can't *find* the corrupted
memos until *after* you've done the compact -- the ERR doesn't show
up until after the compact, in my experience (or not reliably).

The compact is a necessary part of the process for fixing the memo
fields, though, as you point out, it doesn't repair them if the
pointers are corrupted.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #9
"lylefair" <ly******@yahoo.ca> wrote in
news:11**********************@g43g2000cwa.googlegr oups.com:
Looking at this and the related thread, it seems to me you have
spent a lot of time on this problem.
I would have:
a) compiled the report's vb (if there is any) to see if any error
is reported; this should compile all your code, thus identifying
any problem in some code upon which the report depends;
Well, that's good advice *except* that it dowsn't always reveal
corruption in already-compiled code. The only time what you suggest
is completely reliable is if you fully decompile first and *then*
follow your suggestion.

The reason you have to decompile is that the corruption is sometimes
caused by the fact that invalid code is marked as compiled. This
happens because of the way VBA code is compiled -- it doesn't check
the validity of all the code, only of the code that isn't already
marked compiled. Of course, it's supposed to check dependencies and
recompile code marked compiled if that code is dependent on code
that is *not* marked compiled, but the problem with flags like this
is that they can sometimes get out of whack and not represent the
true state of the code and the compiling.

This is what MichKa explains in his article on Decompile, in the
section about the 11 states of VBA compilation.

This is also why it's essential for an Access programmer to turn off
COMPILE ON DEMAND, because it leads to extra compiling that is not
under the programmer's control.

I hit the compile toolbar button a lot (every A2K+ installation I
work on I've had to add it in the VBE; dunno why it's not on the
toolbar by default -- perhaps another foolish inconsistency with the
other programs that use the VBE).
b) saved the report as text and loaded it back in as text; if
there's an error in the report it should NOT reload;
Why wouldn't you do this *first*? It will recreate the module behind
the report, so would likely flush out any hidden corruption there.

Of course, it makes more sense to do this *after* a full decompile,
for the reasons outlined above.
c) deleted the report and recreated it (hoping the new one
works);;
d) asked the access wizard to create a report using the
same recordsource as the problem report (to see if the problem
occurs in something never touched by human hand).

THEN if I had no success I might have thought about table
corruption. If I concluded there night be table corruption I would
have used SaveAsText 6 etc to get a fresh copy of the db tables.

I think this would not have taken me an eternity.


I concur with all of your points, and basically said as much.

At this point, SaveAsText/LoadFromText seems to have gotten him a
working version of the report that doesn't crash, even without all
the other steps.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

2
by: Marc | last post by:
Hi all, I have a problem with managing the interchange between COM/Excel and Python if the user closes the workbook externally. Everything works fine as long as the user only uses the exit...
2
by: DFS | last post by:
Access97: I opened a report, then opened a small form that floats above it and lets you choose report fields to sort on (by issuing the OrderBy statement). Well, apparently OrderBy actually...
0
by: dlieu | last post by:
I've found an odd situation in where the Load event of the active form fires (after the Unload event) when Access is closed. I am able to reproduce this situation in Access 2002 SP3 and Access 2003...
3
by: wandali | last post by:
When I want to edit a MS Database, I have to run the following command: "C:\Program Files\Microsoft Office\OFFICE11\MSACCESS.EXE" "\\Server\Directory\File.mdb" /wrkgrp...
3
by: =B= | last post by:
Hi all, I was wondering if anyone has had any luck with trapping the <BODY> onUnload() event in ASP.NET? The thing is, I'm writing code for an Intranet site. The code makes a call to a...
3
by: mo | last post by:
I have an application that uses Reporting Services. When the user chooses to print a report, they are taken to a window that allows them to fill in parameters for the report. They then click a...
6
by: erick-flores | last post by:
Hello, I want to make a report for a single compressor. Instead of showing a report for all the compressors. I would like to place a button in the compressor form, so whenever I want to display a...
4
by: mdmdmd | last post by:
Hello, I wish to collect 4 files from a user. So I have decided to use tkFileDialog askopenfilename. My problem is that after a few file selections the root window is destroyed (the whole...
3
by: Johnson | last post by:
I'm not sure if this is an IIS 5.1 issue or ASP.NET issue, or Visual Studio 2008 issue -- thus posting to 3 groups. Please don't be offended. The problem I'm encountering is that Visual Studio...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.