i want each instance of my vfp app to create and use it's own temp folder 1

[cfsjohn]

I've chased my tail on this one for days. I need an expert.

I am modifying my vfp app to run from RDP. I am trying to cover every conceivable temp files issue meaning I want to simply not worry about 2 instances of my app using the same temp folder. My users can run multiple instances of my app simultaneously. To make a long story short, I am thinking...when my app starts up, if it could create a unique temp folder and then use that temp folder, there is no way there could be any issues with overlapping temp files. My app is run from a desktop icon with the -Cc:\<home dir>\config.itf (itf is the name of my app). The contents of config.itf is:
TMPFILES=.\temp\itf

The above gets me to where my app is storing temp files in a folder under the app's home named temp\itf

Basically I want to have each instance of the app create a subfolder under <home dir>\temp\itf
So if there were 3 instances of my app running there would be:
<home dir>\temp\itf\instance1
<home dir>\temp\itf\instance2
<home dir>\temp\itf\instance3

I have gotten this far:
modify the config file to run a separate prg named createthisinstancestempfolder.fxp
The contents of createthisinstancestempfolder.prg is:
lcdirtocreate=SYS(2015)
MKDIR (lcdirtocreate)

Modify config.itf to be as follows:
RUN do createthisinstancestempfolder

So in the config file I am telling VFP to run my program that gets a unique name and creates the temp folder. That works.

But, now I need to HAVE that folder name so the next line in the config file can be:
TMPFILES=<the name of the temp folder I just created>

I can't see a way to do that.

Thanks for your thoughts,
John

 

[cfsjohn]

JRB-Bldr,

"Perhaps now is the time...". Those are magical words. Where do you buy that at?

Probably 12 years ago I modified my app so the executable runs on the client. I incorporated an old Doug Henning "start" program that is run on the client machine and checks the server for updates, and updates the client when necessary, and then runs my app.

About a year ago I installed the first customer site where some users access my app via remote desktop. We turned on Hyper-V on the server and they remote to the RDP server which conceptually becomes their workstation. I moved the "client" installation to the users folder on the RDP server (not sure exactly why, I was in a hurry then also). That has worked very well.

My next step was to have all customer sites change to virtualized server's and accessing my app the same way. Once I got into it, I learned about RemoteApp. Then I figured out I could do RemoteApp on a cloud server, and then I got a new customer. To make a long story short, my new customer is scheduled to go live Aug 15. I did not want to order another virtual server at about $5k a pop, so I decided to make this new customer the first cloud server with all users running my app via RemoteApp.

In the past few days I have realized the concept with RemoteApp makes all my "client" stuff completely go away. That is pretty drastic! That means there is only a server installation and all the users are running my app directly on the server, albeit in their own "session". No more mapped drives. No more server at the customer site. No more install on the client workstations. Basically no more anything at the customer site. I can not even begin to tell you what a relief that would be, IF IT ALL WORKS. I have 2 days left to prove it all works or I have to order another virtualized server.

I have pretty much proved to myself it will work but need to do more testing. Right now I am stuck. The hosting company (for the cloud server) sent me RemoteApp icons to run the 3 ITF's (as defined earlier in this thread), on the cloud server. In order for this to work (at least work well and with the least changes), I have be able to do something that at this point is elusive. When a user runs my app using RemoteApp, it needs to work exactly the same as if I were using remote desktop connected to the server at the customer site, and clicking the icon on my desktop (on the server at the customer site), to run my app. I have been doing that for 12 + years when I need to run my app on a customer's site.

That is not what I am getting. With so little time, it sounds like you and Olaf and the others on this site have been thru all this and may be able to help. I would sure welcome that help. Before I show you all the guts from the RemoteApp connection, am I right? In order to make this work with the least changes, all the RemoteApp users SHOULD run the app exactly the same as if I were using remote desktop and running the app by clicking the icon on the customer site server?

Thanks,
John

 

[Olaf Doschke]

In the past few days I have realized the concept with RemoteApp makes all my "client" stuff completely go away

That's not just happening with remoteApp, that already is the nature of running an application via remote desktop, as that also doesn't need a per user installation on the server, when you make use of TEMP (which VFP doe s by default, as learned here) and USERPROFILE (for any user specific settings and data. In the long run avoiding having local data in the user profile and also store such things in the backend.

You also still have mapped drives on the terminal server, if data would still reside on yet another file server, but of course it helps to have data local, which makes data access faster and still keeps it at one place. That's a big advantage of having the clients working on the server, though server sessions are not that scalable by just adding more RAM to the server, it has an end, if resources are drained, mostly also CPU can't be scaled up inifinitely.

In the end a web application solution also needs to scale up by using multiple server nodes, you get to a point where data surely again is separated, but that should be SQL Server, not DBFs. Or you have per customer installations, which each have lower scaling needs. But the big advantage of a real cloud solution not running a desktop exe server side but a web application really being the middle tier between clientside browser frontend and data backend, you gain the ability to only have one installation for all clients.

Bye, Olaf.

 

[cfsjohn]

Olaf, All very important things to think about when I become a web app.

I have run into another issue: In my app I issue getenv("userprofile") to know the users folder is so I can write reports to the users folder. When on the remote server, that would be the users folder on the remote server. I need the users folder on the client's workstation. I know the local resources must be available but I do not know what the equivalent of getenv("userprofile") would be in order to get the Client workstation's userprofile.

Thanks,
john

 

[Olaf Doschke]

I don't think local resources are available. Not by default. For a remote app local means the server, the client is a remote machine. Just because the graphic flows to clients, you don't have access to the client side hard drive. In RDP files you will need to specify shared local resources.

If you store to the roaming profile your files theoretically will go to anywhere a client logs in, but that will need a re-login, I assume.

The one info you have about the logged in client is GETENV("CLIENTNAME"), within a LAN that may give you enough information to store something via UNC paths, I am not aware of how to cope with that problem in a RemoteApp cloud solution. In general, a web-app would create such files locally and then offer downloads of PDF or something like that the client is able to process locally.

Bye, Olaf.

 

[cfsjohn]

And if I understand what I have read on the net correctly, CLIENTNAME will most always be \\tsclient\c. I guess I am thinking with different client's OS \\tsclient\c\users\username would not necessarily always be the client's folder.

For lack of a better term, my users are technically challenged (like me). Many barely know how to turn the computer on. I write things like pdf's and spreadsheets to their "local users folder" rather than ask where to put them. yes, there are drawbacks to that but it is what it is.

I really hate sending those reports to something like \\tsclient\c\user\username but I guess as long as I check to ensure the folder exists it will work for now.

Thanks,
John

 

[Olaf Doschke]

No, in a LAN solution I maintained CLIENTNAME really was the computer name of the client within the domain. It might be \\tsclient\c for lack of the outside client anywhere in the world being part of the domain, I never was in that situation to tell about that cases.

Anyway it is, that's where such applications fail to get hands on the client side, just like a web application has no access to the client side file system but the small contingent any browser offers for local storage. This is the isolation level you have with apps not running client side.

Bye, Olaf.