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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
Re: are datasessions bleeding thru> FoxInCloud Support - Thierry N.
Tuvia Vinitsky
Apr 26, 2012 @ 12:39am
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
-- thn (FoxInCloud)
Re: are datasessions bleeding thru> Tuvia Vinitsky
Thierry Nivelet (FoxInCloud)
Apr 26, 2012 @ 01:01am
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
Re: are datasessions bleeding thru> FoxInCloud Support - Thierry N.
Tuvia Vinitsky
Apr 26, 2012 @ 01:13am
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
-- thn (FoxInCloud)
Re: are datasessions bleeding thru> Tuvia Vinitsky
Thierry Nivelet (FoxInCloud)
Apr 26, 2012 @ 03:04am
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
The problem is repeatable only when the recordsource is an alias and the alias is different than the actual table/dbf name.
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
Re: are datasessions bleeding thru> FoxInCloud Support - Thierry N.
Tuvia Vinitsky
Apr 27, 2012 @ 05:48am
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
-- thn (FoxInCloud)
Re: are datasessions bleeding thru> Tuvia Vinitsky
Thierry Nivelet (FoxInCloud)
Apr 28, 2012 @ 09:28pm
In a stateless environment, nothing should be based on a user ID. It should be a session ID only, which is usually passed by http or by cookie.
data Pathes can be found in Users table
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
Re: are datasessions bleeding thru> FoxInCloud Support - Thierry N.
Tuvia Vinitsky
May 2, 2012 @ 02:22am
session ID == unique browser instance
one session ID per user ID
Any new session under the same user ID closes previous session.
Only wUserDemo allows several sessions active under the same user ID
&& awServer .prg
wUserDemo = .NULL. && Demo User ID: this user my have several sessions opened simultaneously
In a stateless environment, nothing should be based on a user ID. It should be a session ID only, which is usually passed by http or by cookie.
data Pathes can be found in Users table
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
-- thn (FoxInCloud)
Re: are datasessions bleeding thru> Tuvia Vinitsky
Thierry Nivelet (FoxInCloud)
May 2, 2012 @ 03:09am
user ID == application unique user ID
session ID == unique browser instance
one session ID per user ID
Any new session under the same user ID closes previous session.
Only wUserDemo allows several sessions active under the same user ID
&& awServer .prg
wUserDemo = .NULL. && Demo User ID: this user my have several sessions opened simultaneously
In a stateless environment, nothing should be based on a user ID. It should be a session ID only, which is usually passed by http or by cookie.
data Pathes can be found in Users table
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
Re: are datasessions bleeding thru> FoxInCloud Support - Thierry N.
Tuvia Vinitsky
May 2, 2012 @ 03:14am
See elsewhere, sessionID is not a unique instance, it is unique only to the machine with the cookie.
user ID == application unique user ID
session ID == unique browser instance
one session ID per user ID
Any new session under the same user ID closes previous session.
Only wUserDemo allows several sessions active under the same user ID
&& awServer .prg
wUserDemo = .NULL. && Demo User ID: this user my have several sessions opened simultaneously
In a stateless environment, nothing should be based on a user ID. It should be a session ID only, which is usually passed by http or by cookie.
data Pathes can be found in Users table
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
-- thn (FoxInCloud)
Re: are datasessions bleeding thru> Tuvia Vinitsky
Thierry Nivelet (FoxInCloud)
May 2, 2012 @ 03:26am
Though sessionID and userID are different, they always map 1-1 at a given moment
See elsewhere, sessionID is not a unique instance, it is unique only to the machine with the cookie.
user ID == application unique user ID
session ID == unique browser instance
one session ID per user ID
Any new session under the same user ID closes previous session.
Only wUserDemo allows several sessions active under the same user ID
&& awServer .prg
wUserDemo = .NULL. && Demo User ID: this user my have several sessions opened simultaneously
In a stateless environment, nothing should be based on a user ID. It should be a session ID only, which is usually passed by http or by cookie.
data Pathes can be found in Users table
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
Re: are datasessions bleeding thru> FoxInCloud Support - Thierry N.
Tuvia Vinitsky
May 2, 2012 @ 03:38am
This was lately called MDI
No they do not, as you yourself said. User XYZ logs on 2 times concurrently from the same browser, separate tabs/windows, he has the same app user id and the same session id.
Though sessionID and userID are different, they always map 1-1 at a given moment
See elsewhere, sessionID is not a unique instance, it is unique only to the machine with the cookie.
user ID == application unique user ID
session ID == unique browser instance
one session ID per user ID
Any new session under the same user ID closes previous session.
Only wUserDemo allows several sessions active under the same user ID
&& awServer .prg
wUserDemo = .NULL. && Demo User ID: this user my have several sessions opened simultaneously
In a stateless environment, nothing should be based on a user ID. It should be a session ID only, which is usually passed by http or by cookie.
data Pathes can be found in Users table
.wUserSet() does Lookups(Users.dataPath, userID, Users.userID', 'userID') and reUSE tables accordingly
Please see this post for further details
http://west-wind.com/wwThreads/Message3HM0BHDLO.wwt
The old app had no provisions for mult data sets. I have the code open here. I see it was planned, but everything was assumed to be in the same database, which is impossible in the real app, not to mention that the app uses free tables which are created elsewhere and over which the app has no control. The original app could was no set to deal with any of that.
What code would you like me to move where? Why would that change anything? I was hoping for an answer as to why a grid would ever see a recordsource of a grid in another session. You cannot just say move the code if their is really a breach going on. Changing the recordsource on a grid incorrectly is not a minor matter.
No FiC apps that I have seen have been put thru the paces on true multi data sets. Quite different than multiple users in the same database. I am trying to lcoate the problem, but I could use any help you might think of.
Again so far this seems very specific to the grid control.
The October application did have provisions for multiple data sets, like any application we adapt to FiC
Move your code to wUserSet on the model of the october application and it'll work.
Let me know if you need face to face assistance, we need to get this app to production.
The October application was single client and had no provisions for multiple data sets, so that is not a basis for comparison.
The problem is specifically with grids and using a table with an alias, i.e.one session has
and another session hasuse temp34333.dbf alias mydbf
. The grid has a recordsource of alias and mydbf. Just playing around with a small grid with 2 fields II was able to reproduce the problem, although I cannot yet tell exactly where it happens. The grid makes tracing a bit more complex.use temp1111.dbf as mydbf
Tuvia,
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).
HTH,
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 = " CURSOR webtemp READWRITE nofilter "
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
ENDIFUSE (_SCREEN.ClientDataPath + "carriers") IN 0
USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo
USE (_SCREEN.MasterDataPath + "uploadshistory") IN 0THISFORM.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?
-- thn (FoxInCloud)