Hi! Rick.

I've asked a question before, but there are still some bugs in wwSession-LocateSession() and wwSession-IsValidSession().

It looks like you should change the code as below:

For your information, I'll leave the link to the question I asked before.

https://support.west-wind.com/Thread5FQ161FNN.wwt

current wwSession::LocateSession():

IF !llIgnoreTimeout
   ~~~
ELSE
   SELECT TOP 1 * FROM wwSession ;
   WHERE SessionId == lcLocateId ;
   ORDER BY LastOn DESC ;
   INTO CURSOR __TSession

   IF _tally > 0
      SCATTER NAME THIS.oData MEMO
      THIS.cSessionId=wwSession.SessionId && Sometimes wwSession.SessionId and lcLocateId are not the same.
      this.oData.LastOn = DATETIME()	   
      llResult = .T.
   ELSE
      SCATTER NAME THIS.oData MEMO BLANK
   ENDIF

   USE IN __TSession	
   SELECT wwSession
ENDIF

wwSession::LocateSession() after change:

IF !llIgnoreTimeout
   ~~~
ELSE
   SELECT TOP 1 * FROM wwSession ;
   WHERE SessionId == lcLocateId ;
   ORDER BY LastOn DESC ;
   INTO CURSOR __TSession

   IF _tally > 0
      SCATTER NAME THIS.oData MEMO
      THIS.cSessionId=__TSession.SessionId && __TSession.SessionId.SessionId and lcLocateId are always the same.
      this.oData.LastOn = DATETIME()	   
      llResult = .T.
   ELSE
      SCATTER NAME THIS.oData MEMO BLANK
   ENDIF

   USE IN __TSession	
   SELECT wwSession
ENDIF

current wwSession::IsValidSession():

LPARAMETERS lcSessionId, llIgnoreTimeout

*** Check for existance and timeout
IF THIS.LocateSession(lcSessionId, llIgnoreTimeout)
   THIS.oData.LastOn = DATETIME()
   THIS.oData.Hits = Hits + 1 && wwSession.Hits is not right here
   THIS.cSessionId= THIS.oData.SessionId
   RETURN .T.
ENDIF

THIS.cSessionId=""
RETURN .F.

wwSession::IsValidSession() after change:

LPARAMETERS lcSessionId, llIgnoreTimeout

*** Check for existance and timeout
IF THIS.LocateSession(lcSessionId, llIgnoreTimeout)
   THIS.oData.LastOn = DATETIME()
   THIS.oData.Hits = THIS.oData.Hits + 1 && && THIS.oData.Hits is right here
   THIS.cSessionId= THIS.oData.SessionId
   RETURN .T.
ENDIF

THIS.cSessionId=""
RETURN .F.

Thanks - updated.

What are you're doing to lose the wwSession table? That should always be in scope and available. I've never seen that fail.

But... the updates are certainly more reliable.

+++ Rick ---

Environment:
UI: smart client - based on VFP form
Server: Windows Server

I can't explain it well. Anyway, I'll give it a try.

When a user enters the ID and password on the login form and sends them to the server, the server checks whether the user is a valid user or not.

If there is no problem, the server sends the Session ID to the client.

The Session ID is always sent together whenever the client needs to call the server. The server uses the Session ID to check the user's validity in MyProcess::OnProcessInit().

After logging in, it could not be in scope when the user makes another call.

I hope you understand what I mean.

I understand what you're doing but it doesn't make any sense that wwSession would not be in scope unless you have a customized version since LocateSession() selects and uses wwSession, as does the code in IsSessionValid().

IAC - it doesn't matter. Your fix is the more reliable way that should always work correct even if the table is not available or in a different workarea. I was just curious what would cause the wwSession cursor/table to not be available or selected in that scenario.

It's really old code (all the way from v1) and it has been refactored a ton - I think in the beginning all of that logic was in a single method and that's why the cursors/table field references were used. The .oData member was introduced a little later but not all the code was updated to it (because it didn't really need to).

+++ Rick ---

In wwSession::LocateSession(), the code uses the locate command to find the record of the client session ID when not ignoreTimeout.

Therefore, wwSession points to that record.

On the other hand, the code uses the SELECT - SQL command to find the record when ignoreTimeout.

WwSession doesn't point to that record in this case, but __TSession has it.

Thanks.

Sort of - by default FoxPro returns filtered tables if the query returns all the fields. That's why it works most of the time. There's some odd scenario where it must be forcing a separate temporary table instead of a filtered table.

Again - just a curiosity, and I've made the change so it should be consistent now.

+++ Rick ---