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
|
Back to Table of Contents
Copyright © 2002-2018 by Tamar E. Granor,
Ted Roche, Doug Hennig, and Della Martin. Click for license
.