Vars in multiple threads

[omni]

Roger,

We have a user that is having date overwritten with info from another record. After researching the most recent one, this is what is occuring:

User has what we call a booking record open and adds a new record. It has many buttons once added, and he leaves it there after clicking save.

he opens another menu option to dispatch another booking record. There are no public vars in our system, as a note. The display for the dispatch loads the same vars for this booking record. He then dispatches.

He goes back to the original window and clicks save (for no apparent reason, but normally no harm). The info from the 2nd window is saved in the first window, thus overwriting the particular fields that were in both windows. We have never seen this at any other location for the 10-12 years we have been using alaska/express.

Is this even possible? (I guess it is since it is happening)

Fred
Omni

[rdonnay]

Databases are always public.
If you are writing to a database in one thread and viewing that database in another thread, the data would get updated in that other window.

It appears that you have a lot of issues.
When my other eXpress++ customers have this many issues to resolve they choose to hire a few hours of my time, using TeamViewer, to work through all of them.

[omni]

Guess I did not explain enough. We are aware of what you are saying, and we have hundreds (over 1000) that have these windows open all day. This is ONE user in one location, and the problem is the variables assigned in one thread are updating the other thread. When save is selected, the pro (record) is seeked again, and reverified. The system logs this. The record was correct in the log file, the
fields were updated by the variable in another thread (or that is what it appears). Cannot duplicate using any method in their network, nor ours
As a note, the other thread does not update anything in this file, only reads it.

It acts as if the vars are public, which they are not.

Its one user, so we may do something to get around it, like not allowing a save if too many fields change, (as it changes 50+ fields). Very rare and probably not worth the time to figure out for one user that happens once a month or so.

[rdonnay]

This is very strange. Local and Private variables are supposed to be thread-safe.
I have never heard of a situation in which they are not.

[omni]

Me either, so my log file may be giving me the wrong impression, and it may be a coincidence that he dispatched that load at about that time. Maybe he somehow pulled up that pro (the one he dispatched) or attempted to and the var for the pro number was not reset, which seems impossible. I am going to add logic to check for too many fields being updated and give a warning message to alleviate.
It would be different if it had ever been reported before in all these years, so its something in his environment....and all just within the last few months.

Thanks. have a good holiday.

[Cliff Wiernik]

You are not editing in a DCGET the database variables directly, like in cAlias->fieldname.

That can cause problems if you have a browse or some other method of looking up a desired record. We were just displaying the field from the database like we did in clipper. Get was edit protected. We resolved by changing the DCGET cAlias->fieldname to DCGET bblock with bblock := {|| cAlias->fieldname}

Was hard to track down but it was the cause.

[omni]

No, we never do that. We always use variables for all views and updates, with the exception of dcbrowse fields, which in our set up are never editable.

[Auge_Ohr]

... we have hundreds (over 1000) that have these windows open all day. This is ONE user in one location, and the problem is the variables assigned in one thread are updating the other thread.

so it does not happend on your PC ?
did you ever think about that User / PC is different ... change Hardware

about Thread and Vars : i use #xtranslate and a 2-Dim Array this Way with old Cl*pper Style:

Code: Select all

   nThread := EDIT_INIT()
   oEdit   := WM9EDIT(oDlg,nThread,oBrowse)
...
   EDIT_EXIT(nThread)

so every Thread got a own set of #xtranslate

Code: Select all

// Sample using 2-Dim Array
#xtranslate mW9MARK     => Stack\[SP,1]
#xtranslate mW9VIDEO    => Stack\[SP,2]
...
#xtranslate mEditRec    => Stack\[SP,18]

STATIC Stack         := {}
STATIC SP            := 0
STATIC aEditControls := {}

FUNCTION EDIT_INIT()
   AADD(Stack,ARRAY(18))
   SP ++
   EDIT_LEER()
RETURN (SP)    

PROCEDURE EDIT_EXIT(nThread)
LOCAL iMax
   ADEL(Stack,nThread)
   DO WHILE .T.
      iMax := LEN(Stack)
      IF iMax = 0
         EXIT
      ELSEIF Stack[iMax] = NIL
         ASIZE(Stack,LEN(Stack) - 1)
      ELSE
         EXIT
      ENDIF
   ENDDO
   SP := LEN(Stack)
RETURN

STATIC PROCEDURE EDIT_LEER()
   mW9MARK     := " "
   mW9VIDEO    := SPACE(120)
...
RETURN

PROCEDURE EDIT_STORE(nRecno,nThread)
FIELD W9MARK
FIELD W9VIDEO
...
   IF PCOUNT() = 2
      SP := nThread
      mEditRec := nRecno

      mW9MARK     := W9MARK
      mW9VIDEO    := W9VIDEO
      ...
   ENDIF
RETURN

STATIC PROCEDURE ST_REPLACE(nThread)
FIELD W9MARK
FIELD W9VIDEO
...
   SP := nThread
   GOTO(mEditRec)
   Gather(aEditcontrols)

   IF (DBRLOCK(mEditRec))
      FIELD->W9MARK     := mW9MARK
      FIELD->W9VIDEO    := mW9VIDEO
      ...
      (DBRUNLOCK(mEditRec))
   ENDIF
RETURN