No. What did you get, when you tried it? Error "Datasession number is invalid". When you start VFP itself or an EXE you only have one datasession. And you don't start a new datasession by SET DATASESSION, that command can switch the current datasession, but can only switch between existing datasessions.
Before I go on, notice that to be able to make use of the feature of a report to use the already available cursor in the current workarea of the current datasession, you don't want private datasessions, you want a report to stick to the current datasession, to be able to see all workareas in it and
not start from scratch. So I guess you're on the totally wrong track about private datasessions being good for this. They are good for other reasons and scenarios and in general to separate the usage of tables and not muddle where record pointers are, etc. between parallel running forms, but not good for this case.
So I'll explain something about the wrong track, it'll be helpful to not get there and know what to set where, in the end.
So, explaining the nature of datasessions, especially private ones:
To create a
new datasessions you need forms configured to have a private data session or reports configured to have a private datasession or you create a session object. Session is a native VFP class, albeit a nonvisual class. It's irrelevant for this discussion, I only mention it for sake of completeness of where new datasessions can come from.
The term private is atually not really relevant, literally. It's private, because by definition it'll be a new datasession no other code or object has yet used, because it's new and so nothing had the chance to use it beforehand. A private/new datasession starts empty, unless you add in tables, views, etc into the DataEnvironment of a report or form, which is determining what's done initially at form load or report run, in the new or old datasession a report or form uses.
SET DATASESSION does set a spcific datasession
number, by syntax definition:
help said:
SET DATASESSION TO [nDataSessionNumber]
The help goes on about this number here:
help said:
A form's DataSession property determines whether the form has its own unique data session when the form is created. If a form's DataSession property is set to 2, the form has its own data session; otherwise, a data session is not created for the form. [highlight #FCE94F]You can use the form's read-only DataSessionId property to determine the form's data session number[/highlight].
There are two datasession related properties of forms (and bear with me, I get to reports, again, in a moment):
Datasession is not the datasession number, DatasessionID is the datasession number, and is read only. With the Datasession property you only determine whether you run the form in the current datasession by setting Datasession to 1 (=default or better yet current datasession) or start a new datasesion by setting it to 2 (=private or better yet new datasession). What datasession number that will be is only known at runtime and will be available in the DataSessionId property. There can be as many datasessions as you run forms or reports set to private datasession in parallel, not only 1 or 2.
The meaning of 2 as private datasession of the Datasession property of reports and forms is not the same as DatasessionID 2, and I know that is confusing, but VFP is designed that way, I would have opted for a property NewDatasession instead of Datasession, that could be .T. instead of 2 or .F. instead of 1 and would make things much cleaner and clearer. And Set Datasession could also be clearer if it would be SET DATASE$SSIONID, although that would also be confusing, as the datasesisonid of a form or report is readonly and can't be changed. Well, SET DATASESSION switches the current datasession, it's not useful to you, forget about its existence, you'll only need this when you would program in OOP paradigms and would need access to datasessions of multiple forms that each have separate sessions. It's of no importance for reports using a cursor you prepare before the actual report run.
Now about reports: Reports don't show up in the properties window, for sake of setting a report to a private datasession or not, there's a menu item in the Report menu:
This can be ticked or unticked, so for reports this "property" is designed as it also should be for forms, as a boolean yes/checked or no/unchecked value.
What you want, when you want to run a report with the available cursor you popuplated with report data as you want to print it, is a report that has that
unchecked. Because the current cursor is in the current workarea and that's in the current datasession number, not in a new/private one, that would not yet exist. So I explained a lot of things you actually didn't need to know for that sake of using a report with data prepared in a cursor. The cursor will always be in an already existing datasession and not be available in a new private datasesssion. So private datasessions are not what you need for this scenario, they would actually hinder usage of a prepared cursor for a report. The least thing you would need to do to use that same prepared data with a private datasession is a) store the cursor into a DBF and b) use that DBF in the report. But that's just overcomplicating things. It's far easier by having the report cotinue in the same datasession as whatever calls the REPORT FORM is already using. And what's in the report data environmen would only add to what's already open in the datasession, not override or replace it.
[highlight #FCE94F]Edit (important):[/highlight] If you already have reports with private datasession you'll not alwayss have it as simple as unchecking the menu item "Private Data Session", because the dataenvironment of the form would still open tables according to what you have visually in the report data environment and maybe override what already is open and cause harm in record positions, buffer states, etc. A report with no private datasession used with a prepared report cursor should not itself have anything in the reports data environment that could muddle with already open tables, etc. So it's not always easy to switch the strategy of a report with its private datasession and environment determinig its data to a report that instead is driven by a cursor prepared outside of it and before it runs. Maybe you're dealing with that problem.
The topic of multi user environments is also not simply about private or non private datasessions. The major thing to do with multi useer environments is to use tables shared. That's shared file access, not shared datasessions. You don't share a datasession with a second user anyway, datasessions are part of the process (EXE process) of a client and in that sense are all private to one user, because datasessions are not living in the network shared with users. What's shared is DBFs. If you compare a datasesssion to a window to files then you can still see public places, like a shared DBFs, through a window, no matter if it's private or not.
And last not least, calling any non private datasessions public, the public nature is limited in the same manner as public variables are not shared acrosss all clients in a multi user envirnment, public variables are also confined to the local process or one client user. The datasession number 1 is the datasession you start with in which all code outside reports and forms and session objects runs and which is therefore the "most public" datasession. But indeed it's
not seen by a report or form that is set to another, private, own, new datasession, because that's actually what you want, if you want to separate a report or a form from all previously opened tables, created cursors etc. and start in your own datasession for it. It's not separation from all other users, it's separation from other forms or reports. And why would you want that? That's a whole different topic. Ask about it, if you have questions, but that has nothing to do with a report using the current cursor you prepared before running the report.
Chriss
