VFP has the concept of datasessions, with each data session having its own set of cursors etc. Cursor aliases can be the same among sessions.
In X# we have different set of workareas per thread, maybe the concept can be enhanced so it also supports data sessions?
Data sessions info from https://hackfox.github.io/section4/s4g392.html:
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
VFP has the concept of datasessions, with each data session having its own set of cursors etc. Cursor aliases can be the same among sessions.
In X# we have different set of workareas per thread, maybe the concept can be enhanced so it also supports data sessions?
Data sessions info from https://hackfox.github.io/section4/s4g392.html:
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
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 DATASESSIONcommand 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 aSET DATASESSIONTO in a black box, so that you can restore the original DataSessionID again on the way out.We doubt we would use
SET DATASESSIONwithin 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 DATASESSIONcommand—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