Preventing user from opening accde directly but only via another access database.

Hi,

Lately, there was an update of an external app that we connect our access database to, so all tools need to be updated, but some user are still using the older version of that external app. So the deployment was quite painful.
I am now looking to create like a hub that stores all the access tool but user can only access to those tool via this hub. If they try to open directly the accde, it won't work.

So my idea is, creating a Hub and use FileCopy to copy the frontend from server to user local, then using Shell command to open the frontend.
But I also want to prevent user from opening the accde directly from their computer without passing by the Hub so they will get the latest version.

Is there a way to pass variable from an Access instance to another Access instance? Example when they click on Launch in that Hub, it will set the variable to true, then because it's true, the launching tool on open will keep opening. If the variable is false, then in the opening tool, it will prompt, you can only open this tool via the Hub.

Any idea?

Thanks

Not sure I follow the hub idea completely.
However it sounds similar to having a split DB with linked tables in a password protected BE. Once the links are setup there is no need for end users to know the password supplied to make the links

So in your case why not just password protect the ACCDE but don't tell users what that password is.
Then supply the password in your 'hub' code but keep that inaccessible to your users

Hope that makes sense & isn't completely off the point.

isladogs said:

Not sure I follow the hub idea completely.
However it sounds similar to having a split DB with linked tables in a password protected BE. Once the links are setup there is no need for end users to know the password supplied to make the links

So in your case why not just password protect the ACCDE but don't tell users what that password is.
Then supply the password in your 'hub' code but keep that inaccessible to your users

Hope that makes sense & isn't completely off the point.

Click to expand...

No, that’s not my issue to access to linked table with password.
So I have 10 different tool in access, and they are in accde.
Instead of sending to the user 10 accde file, and some user doesn’t even need all those 10 tools. Since there are multiple department involved, instead of pulling my hair to know which department need which tool, i can create a single accde that stored all those 10 accdee.
So the user can select the tool they want to launch and launch from that hub.

Hope it’s more clear now?

Thanks

Hope it’s more clear now?

Click to expand...

Not really

The 'hub' just sounds like a switchboard or main menu screen with various options but you don't want all options available to all users.

The standard method of allowing/preventing access to specific 'features' is to assign permission levels to each user/group of users
Normally there should be no need to have multiple accde files to accomplish that.
However if you do have multiple files, you can still use permission levels.

The reason for suggesting passwords was so that users would be unable to open the accde files directly without knowing the password itself

Hi calvinle. Colin's idea should work for you and have the same effect of preventing the users from directly opening the ACCDE files without going through the hub. But to answer your original question, checkout the /cmd command line switch for Access. Hope that helps...

calvinle -

You can hide the 10 DBs all you like but someone will find them. As long as they are separate Access files, the only way to launch them is through a command line option. You can, if you like, fire off a Shell command that launches the individual tool. From inside that tool that was launched separately, there is no easy way to know that you were launched via Shell or via direct icon-click. And the only way to have that tool not launch is for the tool itself to decide that it should not launch.

You asked about setting a variable. Because the tools are separate files, they have VERY limited points of contact, by Windows rules. Setting a variable TRUE/FALSE is a rough task because these two separate files (the tool and the launcher) are separate processes, so they are FORBIDDEN to interfere with each other's private memory.

If user XYZ is going to be able to run this file AT ALL, the permissions will have to be set to allow it. If the user isn't running as an administrator, you will have a LOT of difficult work to "diddle" with permissions. The better way is for you to have an "Opening Menu" with each tool, have the Form_Open routine check for the run conditions, and then either allow or cancel the opening menu (and in cancelling, terminate the launch.)

The trick, therefore, is to find a way that differentiates between direct launch and some other form of launching. You MIGHT (stress again, MIGHT) be able to do something like planting an obscure environment variable before launching the app and have the app remove that variable. If you have a back-end database table, you might be able to drop something in a temporary table to allow it. But that gets tricky, too.

The icon contains the command line that would launch the app. You would therefore need to assure that the "public" version of the icon doesn't contain what is needed to run the app. The idea from theDBguy is viable, i.e. that from the Shell operation, you can include a parameter using the /cmd option and can, inside the database, use the Command() function to see what was on the command line that launched the app. And you would include this /cmd option (with some text string) that you could use to verify that the correct method was used for the launch.

Here's your next problem. You are doing this because in essence, you do not feel you can trust your users. There is no other explanation that I can see. But if you have the kind of users who cannot be trusted, then this will happen: Once folks see there is a tool there and they can get to it directly, they will figure out what it is that makes the launch succeed. They will figure out how to bypass your safeguards.

The only way that I see to make this strong enough to stop your users that you don't trust is for you to use a dynamically generated key to allow the tool to know that it was launched by someone/something that knows how to generate that key. Maybe the parameter is that you would compute a date/time string; maybe you could compute a hashed value of the username with the current day-number as the hash seed. That would be up to you.

My advice, though, is to REALLY think about why you don't trust your users. What is the point of all this hiding? Can you really not trust them that much? Because that is the only reason I can see for doing this.

Thanks for your opinion. The main purpose is not really about trusting user but to make any of current and futur tool deployment easier.
About that Hub, i can set level access etc so each department can only see the tool they are able to see.
I created my tool in Access and also im Excel to automate task and when a user has issue with the tool due to many factor, I had to ensure they are using the right version etc.

Since we cannot pass variable that way, I have another idea.
Once someone click on that Launch command, it will download a copy of frontend from server to local and create a text file, example: tool_name.txt, then launch the tool, then delete that that text file. When the tool open, if the text file is not present, that mean the tool has been opened directly and not without the hub.

About cmd, I just don’t get how that works..

Thanks

calvinle said:

About cmd, I just don’t get how that works..

Thanks

Click to expand...

Basically, you would use Shell to execute Access.EXE with the /cmd switch plus the "keyword" you want to use and then in the Open event of the launched db, you would use the Command() function to check if the app was opened with a matching keyword. If so, let it run; otherwise, you quit the app.

theDBguy said:

Basically, you would use Shell to execute Access.EXE with the /cmd switch plus the "keyword" you want to use and then in the Open event of the launched db, you would use the Command() function to check if the app was opened with a matching keyword. If so, let it run; otherwise, you quit the app.

Click to expand...

This sounds great. Any site with more info that I can lookup?

Thanks

calvinle said:

This sounds great. Any site with more info that I can lookup?

Thanks

Click to expand...

Well, this is untested, but it might look something like this.


In the launching app:
Then, in the startup routine of the launched app:
Hope it helps...

As for making sure they run the latest copy, I used Bob Larsen's FE Updater code.

This was mentioned here a while back.

https://www.access-programmers.co.uk/forums/showthread.php?t=305052

HTH

Whilst I still think your whole approach is wrong, you could also investigate using the boolean UserControl property.
This is True if opened directly. False if opened via another app.

So use code like

Hey, Col, I was unaware of UserControl. Is that a new feature? Sounds like exactly what calvinle wants.

I've never heard of passing a command line switch using Shell but if that works it might come in handy some day. I've always thought the switch can only be passed to the opening db IF user launched from a shortcut that contains the switch. I know you cannot pass a Command value to a db by another db using the command line. The opening db won't 'load' the switch value into the Command property.

When I read the post, it sounds like any db being opened via the hub is being opened shared. Why else would you place 10 db's in a central point and force anyone to open through there? In order to not share, you would need db1 times x users + db2 times x users + + + ... not 10 db's for everyone to get at.

Micron said:

I've never heard of passing a command line switch using Shell but if that works it might come in handy some day. I've always thought the switch can only be passed to the opening db IF user launched from a shortcut that contains the switch. I know you cannot pass a Command value to a db by another db using the command line. The opening db won't 'load' the switch value into the Command property.

When I read the post, it sounds like any db being opened via the hub is being opened shared. Why else would you place 10 db's in a central point and force anyone to open through there? In order to not share, you would need db1 times x users + db2 times x users + + + ... not 10 db's for everyone to get at.

Click to expand...

Hi,
It’s hard for me to explain. I am currently placing 10 dbs in one but the hub simply manage the “make copy from server to user local then open it”.
It does not store anything except the path of the 10 dbs, and any other excel macros files.

I will test the command later to see if that works, but the copy is not a shortcut of the accde but an actual copy on the user local.

Thanks

Thanks. So it's kind of a repository and everyone gets a local copy from it but every time.

Micron said:

Thanks. So it's kind of a repository and everyone gets a local copy from it but every time.

Click to expand...

Yes exactly. So I can avoid all the front-end/back-end deployment version comparison etc etc. In case I want to stop user from using a tool, i simply remove the path from the hub, no one can access, instead of having to go thru each tool...

The_Doc_Man said:

Hey, Col, I was unaware of UserControl. Is that a new feature? Sounds like exactly what calvinle wants.

Click to expand...

Its been around since at least A2003. See https://docs.microsoft.com/en-us/previous-versions/office/developer/office-2003/aa173472(v=office.11)

I use it in several apps as a means of preventing Access apps being hacked using automation from Excel or another Access app. Like all security measures, its not completely fool proof but it is another useful tool in my armoury to minimise the risk of hacking

I'm not certain whether it could be used in reverse to do what the OP wants but he should certainly consider it.

theDBguy said:

Well, this is untested, but it might look something like this.


In the launching app:

Code:

Shell "c:\program files\path to access\msaccess.exe" "c:\path to file\otherapp.accde" /cmd okay

Then, in the startup routine of the launched app:

Code:

If Command()<>"okay" Then
    MsgBox "You must launch this application from the Hub.", vbInformation,"Not Authorized"
    Application.Quit
End if

Hope it helps...

Click to expand...

This is exactly what I need and it works! Thank you very much.

calvinle said:

This is exactly what I need and it works! Thank you very much.

Click to expand...

Hi. Congratulations! Glad to hear you got it to work. We were all happy to assist. Good luck with your project.