This is absolutely not due to FoxInCloud Application Server.
We have FoxinCloud applications running in production with 10 simultaneous users with no confusion at all between user's dataSessions.
In the application we delivered in October, this code (or similar) was executed in wUserSet(), based on current user ID.
Please watch carefully your code and how it interacts with FAS to fix the problem (as you have FAS source code, you can trace trough it).
VERY DRAMATIC PROBLEM WITH GRIDS SHOW(ING INCORRECT DATA SOURCE:
OK, here is the exact problem. A form with a grid can be called for various clients. Every client has their own set of data completely separate from any other client. There is a shared users table that tells the system where to find the data.
In the form Load I was creating a cursor that was the grid data source. Like this:
THISFORM.DoSqlWebTemp(_SCREEN.ClientDataPath, ;
_SCREEN.MasterDataPath, ;
_SCREEN.Company, ;
_SCREEN.Division,;
'webtemp')
and
procedure DoSQLWebTemp
LPARAMETERS tClientDataPath, tMasterdataPath, tCompany, tDivision, tdbfcursor)
IF tdbfcursor = "webtemp"
lcDBF1 = 'temp' + STRTRAN(SYS(2015),'_','')
lcOutput = " dbf " + lcDBF1
.......
lcSQLView = "SELECT " + ;
"Uploadshistory.uniqueid, " + ;
"Uploadshistory.invoice, " + ;
"Uploadshistory.company, " + ;
"Uploadshistory.division, " + ;
"Uploadshistory.division as div_old, " + ;
"Uploadshistory.code, " + ;
.........
EXECSCRIPT(lcSQLView)
IF USED(lcDBF1)
USE IN (lcDBF1)
ENDIF
IF UPPER(tdbfcursor) = 'WEBTEMP'
SELECT 0
USE (lcDBF1) ALIAS webtemp EXCLUSIVE
ENDIF
This leaves me with a table with the alias webtemp, of which the real source is some random name
Of course, forms in FiC never recall the Load. The main purpose is to seed the grid. So I have to accouint in the Init for that:
lcTempOut = 'tmp'+RIGHT(SYS(2015),9) + '.dbf'
IF USED('carriers')
USE IN Carriers
ENDIF
IF USED('divisions')
USE IN divisions
ENDIF
IF USED('uploadshistory')
USE IN uploadshistory
ENDIF
USE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0
THISFORM.DoSqlWebTemp(_SCREEN.ClientDataPath, ;
_SCREEN.MasterDataPath, ;
_SCREEN.Company, ;
_SCREEN.Division,;
lcTempOut)
USE IN (lcTempOut)
SELECT webtemp
CURSORSETPROP("Buffering",1,'webtemp')
ZAP
APPEND FROM (lcTempOut)
DELETE FILE (lcTempOut)
DELETE FILE (STRTRAN(lcTempOut,'.dbf','.fpt'))
Simple. I have zapped my "webtemp" dbf and appended records from another temp dbf.
Now, after a few clicks in the grid, the grid which was fine suddenly starts to show the same data as every other session's grid.. user 1 logs on, fine. user 2 logs on from different location and different client name. Also fine. But after a few clicks user 2 suddenly sees the grid right before his eyes switch to the data source of user 1!!!!!!!!!!!!! All users start seeing the same grid data!
If you check dbf('webtemp'), every session is now using the same temp-name table as webtemp, and has switched from whetever it started as.
As you can imagine, the client is frantic. He added new clients and this was the result.
The grid recordsourcetype is Alias and the recordsource is webtemp.
What is happening with the grid?
BTW, I can replicate this behavior and demonstrate it on any system.
I have a confirmed report of a form with a private datasession and multiple users accessing from different locations that frequently the grid gets populated with the data of a completely different session. I amm investigating the code; also has anyone ever seen this?