Direct temp tables to user\<userprofile>\appdata folder

[Lesg]

I have a project where we have installed an access application on a Azure multi-user Host VM, C:\MYProgram. As part of the function of the application, during processing temp tables are created, which is causing a problems if two or more users are doing a task that creates any temp tables.

As a workaround, currently we have placed a copy of the application inside each user userprofile\documents folder which works ok. However, we now have to provide the solution as a 'Remote App' via the Windows Remote Desktop application, so need to return the application to C:\MyProgram to add the app to the workspace.

I have looked at MSIX app attach as an option to do this per user, but it's overkill for what we are looking to achieve.

Thanks in advance

[Gicu]

Do you have any kind of starter\launcher for it? You could have the master version of your app (front-end linked to Azure back-end) in C:\MyProgram but all users should have their own copy in their folders. Even when using remote desktop their logins should be unique so they would still have their userprofile folder on the remote server. Have a look at my free utility that I used in similar cases, I would place it in the userprofile folder (all those would need to be set up as trusted locations but that is a one-time operation) along with the personal front-end and set the path to the master as C:\MyProgram.

http://forestbyte.com/ms-access-utilities/fba-db-launcher/

There are also lots of examples of using batch files to do a similar thing, a simple search should return lots of links.

Cheers,

[ranman256]

I use a shared table like that and records are loaded with their IP so they only edit their records.

[Lesg]

Hey Vlad,

Thanks for that feedback, yes users have a login screen. The systems is access front end SQL backend, but the temp tables are created locally within the access FE. All remote desktop access is via their 365 account and using FSLogix each has their own profile containers.

So I assuming you utility uses the 'Master' as the login, and which point they are then sent to their own profile installations, is that correct?

I will download and take a look at your utility, thank you.

[Lesg]

Hey thanks for that. As they are in the same office location they are all on the same IP address, so this solution would not work for me in this case. Thanks for the suggestion though, it could be an idea in other situations.

[Lesg]

Hey Vlad, so I have downloaded your example, but do not seem to be able to try it as i cannot add anything in the fields, so I am assuming the following:

For Front End name we would add: MyProgram?

For the Master Front end field we would add: C:\MyProgram.accdr?


Then for the Personal folder we would add: C:\Users\<myprofile>\AppData\Local\Programs\MyProg ram.accdr (can we user %USERPROFILE% or do we need to add as per the user profile name)?

Not sure what the 'same folder as launcher' means assume this is as the master front end?

With auto run selected assume this would create the process of checking and sending the user to their personal FE?

[Gicu]

Hi,
The controls are just locked, you can double-click the fields and it will parse the path and the names for you (or you can simply open the table and populate it there). If you have the Same folder checked then you can leave the Personal Front-End folder path empty (the launcher needs to be inside the same folder with the personal front-end in each individual profile).
The launcher's main usage was to distribute front-end updates; you would need to import from it the usysVersion table (and maybe the frmVersion form to embed it into your own main switchboard or opening form). You will need to go to FileOptions\Current Database and under Navigation Options turn on View system objects.
When a user double-clicks the launcher's icon on the desktop it will open check if the master version in C:\MyProgram has a higher version number than the local one, if yes it will make a back-up copy of the local one (in case user needs to import any modified objects from it such as customized queries) then copies the master copy and opens it.

CHeers,

[NoellaG]

Hi, another option to consider. If you have a SQL server backend and every user logs in with hers/his own account: why not create the temp tables on SQL server in the user session? If each user has its own session they can exist independently.