04:04:36 AM
3HL08QLSG
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 ENDIF USE (_SCREEN.ClientDataPath + "carriers") IN 0 USE (_SCREEN.ClientDataPath + "divisions") IN 0 && has each division's logo 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?