"David W. Fenton" <dXXXfenton@bway.net.invalid> wrote in message
news:Xns96D24E86B263dfentonbwaynetinvali@216.196.9 7.142...[color=blue]
> MLH <CRCI@NorthState.net> wrote in
> news:ffohi1dm7hrvg3tbet9ms6e12i66cj0r96@4ax.com:
>[color=green]
> > 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.[/color]
>
> 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[/color]
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.
