Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Ken Murphy
  Where is Ken Murphy?
 Springhill
 Canada
 Ken Murphy
 To: Ilya Rabyy
  Where is Ilya Rabyy?
 Fountain Valley
 California - United States
 Ilya Rabyy
 Tags
Subject: RE: Form's DE 2 Report
Thread ID: 143325 Message ID: 143413 # Views: 2 # Ratings: 0
Version: Visual FoxPro 9 Category: Reports and Printers
Date: Tuesday, August 28, 2007 5:04:14 PM         
   


> >
> > Ilya,
> >
> > Check out Rick's and Barbara's reply. A little bit of a background on what they are talking about might help.
> >
> > First, lets begin with the data session itself. You can have a large number of data sessions - if you wanted to get stupid about it you could even open up a new session for each form and report. Each data session is completely different and autonomous from any other data session. Move a record pointer on the Customer table in one data session and it will not affect the record pointer on the customer table in another data session.
> >
> > When you load up VFP (or when you run an app) VFP loads up an empty data session. You can then open tables, views, cursors and CA's in that session. You can think of a data session as a container (and yes, it is a type of container) to hold these open tables, views, etc. Each table, view, cursor, CA, etc. will be represented by an alias. The big rule here is that you can only use an alias once per data session. You cannot have a table and view opened, both with the same alias of "customer."
> >
> > Lets say you have a customer maintenance form that displays all the information you have on a customer. Your user already has the customer form open and is working on changing a customer address. Now the phone rings and it is a different customer on the phone asking questions. Your user opens up another instance of the customer form, looks up that telephone customer, finds the required information and does what ever is required. The user then closes the second instance of the customer form, returns to the original instance and continues with that address change. This second form needs to use a new data session. If you were to use the same data session that the original form was using, when you looked up the telephone customer, you would any changes to that address that you had not yet saved.
> >
> > When VFP opens it opens up a new data session (we will call it data session 1.) If you leave the form's .DataSession as Default and you open several instances of that form, they will all use the "default" or "current" data session - in this case, data session 1. This means that two instances of that customer maintenance form will both use data session 1. Note that a cursor/table/view/ca alias can only be used once per session so you have to:
> >
> > IF NOT USED([Customer])
> >   USE Customer IN 0 SHARED
> > ENDIF
> > 

> > If your customer maintenance form had a default data session, you would be attempting to open the customer table each time you opened the customer form. Because the first instance has Customer open in Data Session 1, it will not open that customer table again.
> >
> > Now, if you were to set that form's .DataSession property to Private, each time that form was opened it would create a new data session and open those same tables in that new data session. VFP would open up DataSession 1, when the first instance of the form was opened it would create DataSession 2, and when you re-open that form again, it would use DataSession 3. When you open that second instance in data session 3, it WOULD open the customer table as Customer is not currently open in DataSession 3
> >
> > Perhaps it is the naming convention used here that is the difficulty. You can choose between default and private data sessions. You can read "default" data session as "use the current data session and do not create a new data session." You can read "Private" data session as "Please open up a new data session so what I am going to do will not affect what I am already doing. For example:
> >
> > VFP starts and opens Data Session 1
> > Form 1 - Data Session is Private - it creates and uses data session 2
> > Form 2 - called from form 1 as a modal pop-up form and uses the Default data session. In this case, the current data session is data session 2 so it uses Data Session 2
> > Form 3 - another modal pop-up called from form 2 has a private data session. VFP creates data session 3 and the form opens it's tables/views/what ever in Data Session 3. Data session 3 is now the current data session and if you were to call a report with a default data session, that report would also open tables/views/what ever in Data Session 3.
> > The user closes the report, but the report was using form 3's data session so only the tables/views/etc. opened in the report will be closed. The user closes Form3 and Data session 3 closes along with all of the tables opened in it. The user closes form 2, but it uses Form 1's data session so only the tables opened by form 2 will be closed. The user closes form 1 and it closes Data Session 2 along with any remaining tables still open in Data Session 2. The user now exits VFP (quits the app) and VFP closes data session 1 along with any tables that may be open in that data session (probably just FoxUser.dbf.)
> >
> > So how do you use these data sessions. What Tamar and Bernard were talking about was to programmatically create a new data session object. You can even create data session classes that are all set up for you. You need to note that some commands like SET DELETED are scoped to the data session, so if you are creating and using new data sessions, it would be good if you could use a class that already knew to change the SET DELETED to ON. Obviously, a session class can make a lot of sense, depending on what you are doing.
> >
> > For your report, I am not sure you need to go to a data session class. You can simply use the "Default" or "current" data session. I will assume that your form's data session is set to private (or you only allow one instance of the form.) All of the tables/views/cursors/ca's etc. that you need for your report are already there. Create a SELECT command to pull all of the data you need into a single non-normalized report cursor and then call the report. In your report, leave the data session as default and put NOTHING in the data environment. Your report will see that report cursor you just created.
> >
> > Hope this helps
> >
> > Ken
> > You shall know the truth - and the truth shall set you free. (John 8:33)
>
> Thank you for the lesson, Ken! I truly appreciate yout time and efforts put into it. It's consise and right to the point.
>
> Don't you think it worth being added to FAQ section on the Forum?
>
> Regards,
>
> Ilya

Ilya,

I will see if I can re-work it into an FAQ sometime this afternoon. This was typed "off the top of my head" and specifically deals with your problem, but you could be right - it might make a good FAQ.

Thanks for the brownie point.

Ken
You shall know the truth - and the truth shall set you free. (John 8:33)

ENTIRE THREAD

Form's DE 2 Report Posted by Ilya Rabyy @ 8/27/2007 9:59:56 PM
RE: Form's DE 2 Report Posted by Tamar Granor @ 8/27/2007 10:49:06 PM
RE: Form's DE 2 Report Posted by Ilya Rabyy @ 8/27/2007 11:38:56 PM
RE: Form's DE 2 Report Posted by Yull67 @ 8/28/2007 8:10:34 AM
RE: Form's DE 2 Report Posted by Bernard Bout @ 8/27/2007 11:34:21 PM
RE: Form's DE 2 Report Posted by Ilya Rabyy @ 8/27/2007 11:51:16 PM
RE: Form's DE 2 Report Posted by Bernard Bout @ 8/28/2007 6:52:34 AM
RE: Form's DE 2 Report Posted by Rick Schummer @ 8/28/2007 3:35:09 AM
RE: Form's DE 2 Report Posted by Ilya Rabyy @ 8/28/2007 4:49:47 PM
RE: Form's DE 2 Report Posted by Barbara Peisch @ 8/28/2007 3:53:38 AM
RE: Form's DE 2 Report Posted by Ken Murphy @ 8/28/2007 5:34:46 AM
RE: Form's DE 2 Report Posted by Ilya Rabyy @ 8/28/2007 4:59:07 PM
RE: Form's DE 2 Report Posted by Ken Murphy @ 8/28/2007 5:04:14 PM