Hi Bob,

I am only familiar with mainframe methods of achieving what you describe in your example. And I don't doubt for a moment that what you describe *CAN* be achieved in a PC environment. I just have trouble *ASSUMING* tht it can be done using VFP.

Using your pseudo-code as the example. . .
#1 >Ask client for it's session id?
#2 >If client doesn't have session id, assign a session ID, request login.
#3 >Store login info with session ID.
#4 >Do thing this code does.
#5 >Exit

How do I accomplish #1 - #3 in VFP?

Moving on, here are some other things I wonder about as regards VFP. . .

Variables storage
Does VFP 'getmain' RAM to hold all memory variables defined in the program?... its system memvars too?
If so, does the 'periodic garbage collection' (that some are fond of presuming VFP does) operate on that?

Overlays
Does VFP make use of overlays in its EXE (or DLL?) code that is assembled?
If so, how can it ever operate correctly as 'stateless'?

ActiveX components
Are these 'stateless' in all cases, or does one have to be told if that is the case?

I have other things I wonder about, but these portray the gist of my concerns.

I sure would be GREATLY comforted if there was some passage (from a VFP official source), somewhere, which someone could cite which stastes clearly that this can be done successfully and/or lists any restrictions in doing so.


>>John,
>>
>>I believe that this is a crucial and critical piece of information.
>>
>>Where can I obtain some confirmation that VFP will, under any circumstance (or even under what particular circumstances) create re-entrant (ie "stateless", to use your (and possibly the proper) terminology) EXEs (and DLLs?)?
>>
>>Surely this must be documented somewhere, and I have yet to come across anything wich even suggests it to be true.
>>
>>Jim N
>
>This is exactally what you are doing when you write application for the web using Web Connection, or even when using FoxISAPI...
>
>You have to write your code so that nothing within the object is expected to persists. This doesn't mean that you can persist information with a statless object, you have to store the information and relate it to the user or client as opposed to the current running code.
>
>For eample, when you write an exe that has a UI that is run on someones PC, you can store info in goAPP.UserID since this application always maintains its state, it has one user, and it can store info within it self.
>
>With a stateless object you can't do that. You have to query the client... then restore session info you might have stored about that client. Some pseudo code follows...
>
>Ask client for it's session id?
>If client doesn't have session id, assign a session ID, request login.
>Store login info with session ID.
>Do thing this code does.
>Exit
>
>SO... this object is stateless... since several clients are using its services it can't store info within itself that is related to something outside of itself.
>
>With web programs you use the idea of Sessions. You maintain a database of sessions with info that your ap as a whole may need to access. Every object would have to restore this session info and store any changes to it.
>
>This is how I can have a shopping cart, many shopping carts, call processed with the same code. At any time a client could call the 'AddMyTotal' method... that method would have to ask... ok, what is your cartid... then look up that info in a database and add up the total.
>
>You can certainly do this with a VFP ap.
>
>BOb