Hi Thierry,

In xxxserver.prg, I have several procedures allowing me a direct connection to the folder.
During the first access, the user is immediately and systematically logged out.
At the second attempt, no worries.
Sample code:

PROCEDURE Acces
   IF .NOT. USED ("Dossier")
      USE (Dossier_gparent + "Data\Dossier") IN 5 ORDER Numerodos
   ENDIF
   LOCAL MnumID, lSucces
   MnumID = ALLTRIM (UPPER (Request.QueryString()))
   IF EMPTY (m.MnumID) ...
      lSucces = .F.
   ELSE
      lSucces = .T.
      Mnumdos = Dossier.Numerodos
   ENDIF
   IF lSucces
      THIS.wUserSet(m.Mnumdos)
      IF Dossier.Complet = .F.
         THIS.wFormStandardPage("dooxi.scx", m.Mnumdos)
      ELSE
         ...
      ENDIF
   ELSE
      THIS.wFormStandardPage("Login.scx", "code dossier erroné")
   ENDIF
ENDPROC

Hi Vincent,

Please describe in more details:

• how the user gets logged out, by which action
• where your 'acces' procedure is located and how it's called
• what you mean by 'second attempt', do you follow the exact same steps as the first attempt?

Thanks for your response. In my example, the user clicks on a link.

Eg: https://dooxi.fr/Acces.doo?79285D17-2E9D-4720-K621-3D8B4BZDF309

1) how the user gets logged out, by which action
He clicks, the folder screen appears briefly then disconnection message

2) where your 'acces' procedure is located and how it's called
Acces() is in dooserver.prg. Called by a link

3) what you mean by 'second attempt', do you follow the exact same steps as the first attempt?
Yes, the user clicks a second time

Vincent, you have a line with Use ... IN 5 ..., this is what I call dangerous code. You should never hardcode a work area like that! Instead use IN 0, and reference the table by its name or alias. If the specified work area, 5 in this case, already has a table open, your code will close it. I'm pretty sure that's what happens in this case.

I'll explain with an example. You have code like this:

Use TableA in 0 
Use TableB in 0 
Use TableC in 0 
Use TableD in 0 
Use TableE in 0
Use TableF in 5

The first time you run this code, TableA to TableE ends up in work area 1 to 5. Then in the last line, TableE is closed and TableF is used in work area 5. And your code will NOT work as expected.

Now if you run this a second time, TableE will NOT go into work area 5, since it's already "occupied" by TableF. Instead it will go into for instance work area 6, and your code will work as expected.

Thanks Tore, but my tables are open once, when the application is launched.
It is only as a precaution that I specify its area again, because it is normally already open.

It's only a precaution???? You deliberately use a programming syntax that is dangerous, and you call it a precaution?

The solution I always recommend, is NOT to keep ANY tables open, only open them when needed and then close them. By letting them stay open, your system is very vulnerable to power or hardware failure. VFP9 caches as much as possible, closing a table and re-opening it is almost as fast as keeping it open, and much safer.

Anyway, hard coding the work area is like knowingly sitting on an armed bomb. And it has absolutely no benefit.

This article gives some more details: http://www.tomorrowssolutionsllc.com/Articles/Working%20with%20Work%20Areas.pdf

Please try in dooxi.scx.Init():

procedure init
parameters mNumDos
…
…
if m.this.wlInitFirst
  return
endif
…
if !empty(m.mNumDos) && add these 3 lines
  this.wUserLogin(m.mNumDos)
endif

I had thought about it, but I have other affected screens in this app.
No other solution than to do it for each screen ?

if it works (you did not feedback), you can create a method in xxxFrm:

procedure wUserLoginAuto
lparameters mNumDos
return .T.;
 and vartype(m.mNumDos) == 'C';
 and varSet(@m.mNumDos, alltrim(m.mNumDos));
 and seek(m.mNumDos, …);
 and this.wUserLogin(m.mNumDos);
 and .T.

You just need an additional instruction in your form.Init() code:

this.wUserLoginAuto(…)

Yes, but wUserLogin is not always Mnumdos.
Is there a downside to running a wUserLogin() when the user is already logged in (under the same username) ?

Yes, but wUserLogin is not always Mnumdos

This is internal to your app., outside of FoxinCloud scope; you can just add a parameter to .wUserLoginAuto()

Is there a downside to running a wUserLogin() when the user is already logged in (under the same username) ?

no
however in this case you won't pass the login data and/or you can use thisForm.wUserGet()

OK Thierry, I am in the process of adding this code in the init() of the affected screens.
I will obviously keep you informed.

WITH THISFORM
   IF EMPTY (.wUserGet()) .AND. .NOT. EMPTY (m.Mnumdos)
      .wUserLogIn (m.Mnumdos)
   ENDIF
ENDWITH

It does not work.
But I noticed that we are not disconnected on the 2nd attempt, even if it concerns another folder (link)

But this seems to work (in xxxserver.prg):

THIS.wUserSet(m.Mnumdos)
IF EMPTY (THIS.wUserGet)
   THIS.wUserSet(m.Mnumdos)
ENDIF

Not in production.

<PRE>
      Error:       1737
    Message: WUSERGET est une méthode, un événement ou un objet.
       Code: 
    Program: acces
    Line No:        609
     Client: 109.128.158.221
Post Buffer: 
</PRE>

Try

IF EMPTY (THIS.wUserGet())

Be aware that, by default, xxxServer.wUserAnonymous = .NULL.

Oups ... Thanks !