Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
DataSession, DataSessionID, SET DATASESSION, Set(“DataSession”)
These functions determine whether a Form, FormSet or Toolbar shares the same data environment as other objects in the application or has its own private session.
Usage
oObject.DataSession = nDataSessionType
nDataSessionType = oObject.DataSession
nID = oObject.DataSessionID
oObject.DataSessionId = nID
nID = SET( "DataSession" )
Set DataSession to nID
|
Parameter |
Value |
Meaning |
|
nDataSessionType |
1 |
Use the same default data session that other objects may be using. |
|
2 |
Use a private data session unique to this object. |
|
|
nID |
Integer |
Reports the individual data session if the object's datasession is set to 2 (Private). Otherwise, reports 1, the default data session. |
Set an object’s DataSession to 2 to keep it private. This allows multiple instances of the same object to be running at the same time without interfering with each other. Each form has its own DataSessionID, its own set of work areas, its own record pointers and its own set of aliases. This last is really cool. With a private data session, you can use the same alias every time, something you can’t do with USE AGAIN. You can use the SET DATASESSION command to switch to that private data session. You might want to do this to examine it for debugging. You would also do it anytime you are running generic black-box code that needs to affect the underlying data tables, such as a “Skip” button’s Click procedure in a toolbar. Just make sure to preserve the original DataSessionID if you issue a SET DATASESSION TO in a black box, so that you can restore the original DataSessionID again on the way out.
We doubt we would use SET DATASESSION within an application form—it’s hard to picture a need for a user to jump from one to another data session within the same form. We’ve also heard that data session-jumping can lead to unstable apps even without data-bound controls, and we’re not surprised. However, switching data sessions from a common toolbar or utility program not only makes sense, it is probably the only way to perform some common functions.
You can see which data sessions are active at the moment with the Data Session window’s “Current Session:” drop-down list. Picking a different data session from the list issues a SET DATASESSION command—use it with caution!
Realize that a form’s selection of “Default Data Session (1)” for the data session is NOT the same as selecting the Public (number 1) data session. A default data session is the one that was open when the form was called—if you call a form set to the default data session from a form with a private data session, they share that “private” session. So forms can share a private data session—a nice feature when you need a follow-on dialog within your form. Be aware that once the called form closes, the calling form’s data session appears as “Unknown” in the Data Session dialog; this seems to be a harmless side-effect, though.
A number of SET commands are scoped to a single data session. This is a great way to ensure that your different forms don’t interfere with each other. The SET commands scoped this way are listed in the SET reference.
The DataSession property is read-only at runtime, with the idea that you can’t change your mind after starting a form. The DataSessionID property is initially assigned by FoxPro but can be changed from one data session to another, even to the default data session (1). However, data-bound controls can get awfully confused when you slip the data out from under them.
Example
Thisform.DataSession = 2