I assume your like means your report now works, after you unchecked "Report uses a private datasession".
You still don't get what private datasession means, it seeems to me.
While private datasessions are very nice for forms, as you (or your users) not rarely run several forms in prallel, which then all have their own private datasession not influencing each other apart from still sharing the underlying data stored in the DBFs, but they all have their own workareas, their own record pointer and current record, for example, even using the same DBF, so you can also do things like running the same form multiple times, each positioning on another ID or record number and displaying that.
But reports? The same advantage applies, if you (or your users) would run several reports in parallel, they wouldn't influence and perhaps interfere in a bad way with each other. But what is typical for reports? You run one, you preview and print it, then you may run another, maybe the same report, but filtered differently, maybe a completely different report. How many times in your life did you have the need to run multiple reports in parallel? I don't mean batch print jobs, they're typicallly done in one report run, I mean two different reports. Do you?
If you answer no, like I'd do, you know the advantage of private datasessions for forms becomes a disadvantage for reports, in the normal case. Private datasessions indeed have the same advantage of fully encapsulating what the report prints within the report, within its FRX/FRT file pair and just DO REPORT FORM will do the report, not depending on any preparation, as all is inside it. But to use that advantage code like you do for preparation would need to be within the report. It's possible, but you can't easily use it, as reports still are not classes and objects as forms are. You can for example use parameterized views in the report data environment that filter the data as necessary, but you don't have the WITH parameter clause as you have with DO FORM, you can only define view parameter variables that are seen by the report by being scoped public or private, you can't pass something into a report with a WITH parameters clause. That's the major difference. It's not unusual to use predefined variables visible in a larger scope than just locally. You're in the same situation with forms when you would want to use something as a parameter in a form load event or a form data environment that's not having access to the forms init parameters, you can always see variables scoped private or public.
But generally the easiest way to use a report is with a default datasession, the easiest way to use a form is with a private datasession. And in general, for both forms and reports, the inverse can also be useful, it always depends on the context.
I write this because I have the impression you learn private datasesion is good so apply it everywhere. As you see the opposite can be true as is in use cases of forms vs reports. It's logical you come here, if you have a problem, not if you would have made the right choice. But this is not the first time it turns out the private vs default nature of a datasession is all that needs to change for something to work vs not to work. It seems you're not getting anything you're teached, that's what's so disappointing.
