What's datasession? 7

[Mandy_crw]

As i keep on improving my app, researching and most of the tine asking in this forum to get valuable answers… i came across “datasession” though I've read the definition in the internet, some points are confusing… may i ask from the experts to please explain in the simplest form “datasession”. Thanks and God bless…

 

[Chris Miller]

Of course it's confusing if you google what a datasession is on the internet. Just search the VFP help file, because it's a word with a very broad and general meaning but a much more specific term for VFP. I've described the topic of scope and mentioned datasessions there already, why didn't you asked then?

Well, then you overlooked a lot or took it for granted but didn't get the real meaning of it. First of all, there always is one datasession, the default datasession number 1 whenever you start VFP or your EXE made with VFP. It is the "container" of al your open data, which means it has all the workareas that you hopefully at least know by now. A workarea is where a table is open and has a workarea number and alias name. For example USE pendlog opens pendlog.dbf in the currently selected workarea (and closes what was open in it, if there was something open in it) with the alias name "pendlog". And that shows in (tadaa) the Data Session window.

I don't mean to disrespect you, but asking about datasessions is a bit like asking about what a room is (where tables exist). They are just do natural when you talk about VFP as when you're talking about interior design nobody specifically talks about rooms in a house or flat, it's so obvious that interior design happens in the interior of a building. Datasessions are as natural to any VFP developer as buildings and rooms in them are for interior designers.

VFP doesn't allow you to use the same alias name twice. So what happens, if forms programmed for data to be opened with certain names run twice? They'd not work as reusing the same alias names, even for the same table, is not allowed (unless in the useless case it is the same workarea). It causes errors "File is in use" or "Alias name is already in use."

Therefore you run a form in a private datasession to be able to reuse the same tables with the same names in a new datasession. Or said differently: Datasessions provide separate data environments for forms. Like differnt buildings or flats or rooms. The best analogy perhaps is flats or houses. Say a form is a "kitchen" form with a "kitchen" table and you want to have multiple kitchens, one in each flat of a building, of course they all have their private datasessions, they are all in different separated flats and private then also becomes a natural idea, doesn't it?

I bet you already used datasessions, private ones, as you're hopelessly lost when forms need to use the same tables for themselves and would violate the scope by reusing the same alias names in the same (the global and default) datasession. Remember that term - "scope"? I talked about it in detail and if you didn't know what a datasession is then much of what I said about it was not understandable to you and I wonder: "Why didn't you ask about it, then?"

If you think back into your legacy FoxPro programming times, I'm pretty sure you already know very well what a workarea is - a slot to open one table in, and you likely used strictly assigned workarea numbers as you only had 10 or later 15 of them, at all. That's not how you program in VFP, you access a table much more fluently without numbering your tables but opening them in whatever free workarea with their actual table name as alias, so it becomes flawless to address a table by its name.

And to be able this needs the concept of multiple datasessions to have reusable code that can run multiple similar forms at the same time using the same tables with same name, in separate datasessions.

You will rarely know about datasessions even though you surely were pointed out to have forms with private datasessions and simply did so without asking back or at least asking yourself what this even means. It works, as clicking on forms with each their own private datasessions automatically switches them, so you don't need code to switch them, even though SET DATASESSION is a command doing that. Instead, you simply can work in your code without caring for the active datasession and caring whether the right one is the current one. That's also thanks to any object existing in a specific datasession and working in it. So even just calling code in an object that was created in another datasession acts in that datasession. Even if the code making that call is in another datasession. So it really is a concept that's made so transparent, it is invisible.

But sessions are actually the first concept there is, without them there is no data access at all, neither native DBF nor remote database access and also no matter if using ODBC for such external data or OLEDB provider. Every data is opened in workareas that are part of a datasession.

Chriss

 

[Mike Lewis]

Instead of reading about data session on the internet, you would do much better to consult the VFP Help file - if only because it is specific to VFP. Start with the topic "How to: Use Data Sessions", then follow some of the links from that page, including those under "See also".

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I agree as I also already suggested to search the help and not the internet.

The help is available in the simplest way by starting VFP and pressing F1 at any moment within VFP (F1 also at least once was a standard for any application).

It's also in the internet and of course you also find a lot more than the help online. To get the basics you need, the help is really a good starting point for everything, as it's a 100% complete and very good reference, but also has many How To sections explaining more than just one class or command but whole topics, there are even some walktroughs.

I'm biased to say tek-tips is another great resource, I'm aware there are other forums as well, and then there is

https://fox.wikis.com/.

Right in this moment it's not available and errors with "Service Unavailable", but it will get up again, I'm sure. And there are a few more sites and blogs and persons, but what do I say to stress the point that the help file is your friend? I just mention all this as you surely find useful info and more results in the web, but learning concepts the help is perhaps the best starting point. If you want to have a roundabout approach of learning VFP a better approach is reading a book that is like a roundtrip of the "house" that VFP is, and there are many of Hentzenwerke. There are also tips books that show you some corners of the house. So not all books are for all cases, but the title and abstract of a book should tell you.

It's - as you know - also important to have a forum to be able to ask questions and get interactive. But we can't assume in every answer that anything related to it also needs to be exlplained or is so basic that we even don't consider it unknown. What isn't covered should be looked up and you have the full documentation in the help for that matter.

And then there's the whole VFPX project over at GitHub, including, to close this circle again, an extended and latest VFP help file at

https://github.com/VFPX/HelpFile/

If you search your installed help file for "VFPX" and don't find this self-referential help topic and don't find the VFPX logo in every help page footer then you don't have updated VFP9s own help file to this latest version, which has some corrections, some extensions, some legacy FoxPro help topics and, well, is actively maintained on GitHub with Francis Faure being the project owner. If you speak French, a whole site in French about FoxPro is

http://www.atoutfox.org/),

just for reference of what Francis Faure also does about FoxPro.

I can also completely understand when you feel torn apart about asking or not, as it reduces engagement with threads that become very long, but as also often said, you can start as mana parallel threads and the more direct a question about solution or sample code is related to a thread, the more it belongs into the same, there's no hurdle to also spark a new question and thread or a set of threads to get explained what we may consider common knowledge also from the point of view you already know old FoxPro versions (and not dBase or Clipper, but FoxPro). Again, don't feel discouraged to ask when we ask you to stop a thread, this is not asking you to stop using the forum to ask more. But also don't expect a post to answer everything you might or might not know and is related to a solution.

When you're using a cooking forum it's also assumed you know basics or you wouldn't really have interest in the cooking forum. And when you ask for recipes they use many standard terms without explaining them. Of course they don't. They also may refer you to glossary or basic books, which compares to the help in case of VFP, and the help is so much more than just a glossary of VFP, it's very complete.

Chriss

 

[Mandy_crw]

Hi experts... Thank you so much for that very comprehensive explanation... i need to digest all those info... Thanks for teaching me always....

Thank you myearwood for that very simple yet essential and very easy to understand explanation...

God bless you guys... i always look for revisions to my app for its betterment.... thru your help everyone here in this forum i am able to refine my app... Thanks alot....

 

[Mandy_crw]

Hi everyone... I have made my app that can be opened in two computer in private datasession and the app that is open in file server only with datasession 2... is this correct? Thanks...

 

[Mike Lewis]

I have made my app that can be opened in two computer in private datasession and the app that is open in file server only with datasession 2... is this correct?

No, I don't think it. I haven't been following this discussion closely, so my apologies if I have misunderstood something. However, ...

In general, you are right to use data sessions, and what you have learned in this thread will be valuable to you.

But using private data sessions does not solve any problem caused by two separate programs (or two instances of the same program) running on different computers. Private data sessions are designed to let different parts of the same program use the same data. For example, you might have Form A, which needs to navigate a certain table in a certain way; and Form B which also needs to access the same table. By using private data sessions, each form will be able to work independently of the other. Thus, Form A will be able to open the table, set an index order, move the record pointer, close the table, and so on, and do all of this without affecting Form B in any way.

In a typical application, the user might open, say, a data-entry form for Customer X. But, while that form is still open, the user might run a report which involves scanning the entire customer table. Now, the report will end up with the customer's record pointer at the end of the table. If they both used the same data session, the data-entry form would also be positioned at the end of the table rather than at Customer X, and that would muck things up.

With private data sessions in use, however, the report would be able to move through the table in whatever way it wants, without the data-entry form even being aware of it.

I hope this makes sense.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mandy_crw]

Yes Mike its very helpful… thanks for additional explanation… i am really learning alot from all of you… thanks and God bless…

 

[Chris Miller]

I have made my app that can be opened in two computer in private datasession and the app that is open in file server only with datasession 2... is this correct?

Mike made the major point. Again from me: no.

And you never can have an application only with datasession2, there always is a datasessionid 0, the general and default datasession. It's still separate, the scope is the process, not the LAN. Sessions are per process, not even per computer and surely not for a whole LAN.

The only point two users get in conflict with each other is at the point of the file itself.

I'm sure you still puzzle about the reason of users losing data access and getting errors. If you can't figure it out with the help of learning about all things VFP and LAN, then what should also help is error logging. When what error happens to which user. At best in conjunction with other logs, like Windows event logs that tell you times users log in and out or shut down the system.

Chriss.

 

[ManniB]

In a typical application, the user might open, say, a data-entry form for Customer X. But, while that form is still open, the user might run a report which involves scanning the entire customer table. Now, the report will end up with the customer's record pointer at the end of the table. If they both used the same data session, the data-entry form would also be positioned at the end of the table rather than at Customer X, and that would muck things up.

Mike,

Continuing with your example:
If a user opens a form for Customer X and that form has the table Customers as data-environment, and then you open a second form, which also has the table Customers as data-environment, will the second form automatically open with it's own private datasession, so the records pointer on the first form will not be moved? Or do you have to set the DataSession property to 2 (private data session) for both forms regardless of the data-environment? If so, what's the use of the data-environment property in the first place?

Thanks,
Manni

 

[TamarGranor]

A table isn't a data environment. You can think of a data environment as a container for a bunch of tables to be opened in a given form or report. When the form or report runs, that data environment simply indicates what tables to open. What data session they're opened in depends on the setting in the form or report. So yes, you need to set the DataSession property to 2 in each form to have a separate data session for each form.

Tamar

 

[Chris Miller]

Manni,

I think you meant having the Customers table in the forms data-environment. Well, besides what Tamar already said, the data environment therefore is just encapsulating the organizational usage of a group of tables. You could interpret a DE as a super-USE command that opens several tables and sets them in relations you can visually specify in a form DE. On top of doing that super-USE command for opening tables as specified at form start it also closes the tables - just the tables it opened and which weren't already open.

That this is possible, that tables can already be open and a DE of a form without it's own private DS just is supplementary to an already populated DS should clarify that DE surely isn't the same as DS.

Last not least there is the Session class as basis for formless standalone datasessions. And there is a DE class, and they are different things.
Perhaps remember their meanings this way: a DS is like the room or house you need for the actual tables, and DEs are an interior design of which tables to combine in which ways, which is a plan you can apply to several rooms or you can combine two or more such plans (DEs) in one room (DS).

Chriss

 

[ManniB]

Thank you, Tamar and Chris, for clarifying.

So a datasession is basically an alternative to opening tables again with another alias? An the data-environment is merely an alternativ to opening an closing the tables manually in the Load and Destroy event of a form?

Just out of curiosity: Which way do you prefer and what are the advantages/disadvantages in the long run when the application grows? Do you use datasessions and Data-environments a lot or do you prefer taking care of these things manually?

Thanks,
Manni

 

[Chris Miller]

Manni,

how hard would it be to program a form to use all its tables with say prefix "form1", "form2" etc.? Of course you want to reuse the same alias names to reuse all code about them. Of course there is a merit of programming with variables holding alias names, but that doesn't make that the only good practice.

There are no cons against private datasessions and DEs like there are cons for formsets. If two forms need to share a datasession to not only work on the same table opened again in each their private datasession but the same workarea in the same datasession having the same FILTER set, the same record pointer and the same relations etc, because they really interact on that same workarea, then using a form in the current datasession also makes sense. So you mix it.

DEs are fine since you have the D class and can use it on form classes. The usual solution to work with DEs before that was defining classes only as abstracts to finally have all SCXes based on those classes to have DEs. The DE Class allows usage of the same form with variations of DEs, and since you can use OOP, i.e. subclassing DEs, you can do nice things with that.

Also, don't think in the direction of alternatives that ask you to pick one of them only, when forms have a DE that determines the starting point in data availability, you can then add tables with USE, you're not limited to tables you define into the DE at design time.

Chriss

 

[ManniB]

Chris,

I'm asking because most of the time I was using DE of a form to take care of opening and closing the tables. And I'm always using the same datasession. When I theoretically needed a private datasession, for instance in order to not change the record pointer of a table opened already in another form, instead of using the DE, I opened the table under a different alias in the Load event of the form and closeed it in the destroy event as I was not much familiar with the datasession property. So before I change my approach, I wanted to make sure it's the preferably way to make use of both DE and DS (not any unexpected downsides in the future) by learning from your experience...

Thanks,
Manni

 

[Mike Lewis]

Manni,

If a user opens a form for Customer X and that form has the table Customers as data-environment, and then you open a second form, which also has the table Customers as data-environment, will the second form automatically open with it's own private datasession, so the records pointer on the first form will not be moved

I think the others have already answered this question, but just to clarify ...

First, the data environment is not the same as the data session. I think Tamar and Chris have explained the difference. I'll focus for the moment on the data environment session, since that was what the original question was about.

A form's DataEnvironment DataSession property is either 1 - Default or 2 - Private. "Default" means that the form inherits the data environment session that was in force when the form was opened. "Private" means that the form will have a different data environment session - different from any other form that is currently open.

To summarise (where Form A calls Form B):

Form A's DatatSession   Form B's DataSession   Form A's DataSessionID    Form B's DataSessionID

Default                  Default               1                         1
Default                  Private               1                         2
Private                  Private               2                         3
Private                  Default               2                         2

Any subsequent forms (or subsequent instances of the same form) that are opened with a private data session will have IDs 3, 4, ... and so on.

When I theoretically needed a private datasession, for instance in order to not change the record pointer of a table opened already in another form, instead of using the DE, I opened the table under a different alias in the Load event of the form and closeed it in the destroy event

No, that is not the same as using private data sessions. In the scenario you describe, when you move the record pointer of the second alias, you are also moving the record pointer of the first alias. It is the same table, with the same record pointer.

But if you open the tables in different data sessions, moving the record pointer in one of the tables has no effect on the record pointer of the the other. That's also true of setting the index order, setting a filter, and similar actions. this is what makes data sessions so useful.

I hope I haven't confused you.

UPDATE: Because of a brain jam, I realise that I have been typing "environment" here rather than "session". I've now corrected it. Sorry for any confusion. Not unusual for me these days.

Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

So before I change my approach, I wanted to make sure it's the preferably way to make use of both DE and DS (not any unexpected downsides in the future) by learning from your experience...

The benefits of the D hopefully are clear, you get an organisational class that handles an initial scenario of available tables that also tidies up after itself. You have to watch out about one detail, that's how buffermode is handled when tables are opened by the DE and not USE commands. You have the form level BufferMode and you have the cursor objects in the DE, that's what single tables, views or also Cursoradapters are used there, which have a buffermodeoverride. For the USE command you can enforce one Buffermode for all USE command of the same datasession with Cursorsetprop("Buffermode",0,mode), which also is useful to know in general, many settings you do with cursorsetprop for workarea number 0 mean you make them the default for all future workarea uses.

There is one major downside of the DE, or I would say there was. The architecture to thrive for, 3-tier, is never based on using DBFs but to query data into updatable workareas, like CAs and views do. You could always have used views, but then there always were framework data access classes that always were superior to views. Now that CAs are possible you can have an OOP class structure of them and use them in this desirable 3-tier architecture. It's still just the case the CA introduction didn't have the effect it should have on application frameworks changing their data access architecture to involve DEs and CAs into business objects making best use of this whole platform of opportunities.

For your case of changing from your individual USEs of dbfs to DE it's an advance and you can go for the holy grail going that way. So go.

Chriss

 

[Mandy_crw]

I dont know if this is related to datasession, but in my second app or exe which set to datasession = 2, and last to be closed.. i have this codes to automatically shut down the computer when finished processing all data. but it returned an error "file is not open" then it continues to shutdown the computer still... but im still bothered... and im wondering what is the file that is not open where i already close all table? The shutdown is just taken from another thread and i dont know what is the meaning of N7 -s -T 01.... could you please explain so that ill understand it better... Thanks...

thisform.Release
RELEASE ALL

CLOSE DATABASES

Run /N7 Shutdown -s -T 01

 

[ManniB]

Thank you, Chris, Mike Lewis and Mike Yearwood,
the concept of data environments is now clear to me and I'll take advantage of them in the future and keep the same aliases throughout different forms.
Also it's good to know that using DE and DS is for working with cursor adapters in the future, although I've never used CA so far...

Thanks,
Manni

 

[Chris Miller]

Manni,

what Mike Yearwood said about not using D because he uses data objects is why many don't use DEs, Application Frameworks already make it a totally different aspect to load data than to USE something, even if that's Views or CAs. I think it's time to reconsidering incorporating DEs into the data access architecture of a framework, but that's everybody's own decision.

You don't get around using DS anyway. If you only take one new habit from it, it's mostly using private datasessions. That's a major advance from opening all data in the default DS.

Chriss