>>This bug is huge as far as I'm concerned. There is a workaround, but it requires applying the "fix" to each and every report which is not practical in many applications. We have hundreds of reports and it would take forever to go through each and every one.
>
>Because you can "hot swap" a report in VFP9 SP2, using the CommandClause.File property of the ReportListener, couldn't you apply the fix to each report as it ran? Not ideal, but could help get around the issue.
>
>Your technique is very clever, there may be a way of accomplishing the same workaround using a custom property on a ReportListener, instead of a report variable. Then no modification of the report would be needed.
>
>I'd like to see it fixed too, but my fear is that everytime the report engine is modified, something else breaks. At least we have a workaround for this problem. If another issue is introduced, we may not have a workaround. I have reverse engineered part of the report engine and it is "cause and effect" to the nth degree. You can't change one thing without effecting many other areas.

The bottom line is that have totally messed up the location of the record pointer in many locations. There's a bug that when the Print When logic gets evaluated, it has moved ahead to the next record .. and then it backs up to the correct record when it prints. They really need to fix the entire thing .. and TEST the heck out of it before they release it!!!!!!

The problem with trying to programmatically fix this is that you don't have any way to know which items in the data group header came from a field in the table and which ones are based on something else. You can't just blast every object in the header. Some may come from report variables that need to stay as is. Some may come from other tables which need to stay as is. So I didn't see any way, without modifying the reports themselves, to apply a fix.