Solved How can I restrict the front-end user from editing the queries?

[Khurramshaikh47]

No, the database is distributed in house and the users know better than to mess with it. The .accde does nothing to protect the database. it doesn't stop the users from opening the tables and updating the data directly. It doesn't stop them from creating their own macros or queriees, It only removes the source code. If you need to lock the database, you need to go far beyond just creating an .accde.


Really? You're not even going to take a shot at it?

md c:\SomeLocalDirectoryName
del c:\SomeLocalDirectoryName\BTI_Employee_Database_Testing.accde
copy "\\Book-dc\hr\BTI Employee Database\BTI_Employee_Database_Testing.accde" c:\SomeLocalDirectoryName
c:\SomeLocalDirectoryName\BTI_Employee_Database_Testing.accde

As I mentioned, the database needs to be downloaded to the user's local drive. Do NOT use a server location.

Also, keep in mind that if you use embedded spaces or special characters in path or file names, you MUST enclose the string in double quotes to isolate the offending characters.

Hi, Pat
I have created FE (ACCDE) file on my Local Disk (D
and then created a batch file with .bat extension please check the screenshot below:

Then I created its shortcut on the server location where my backend file and a copy of front-end file is already exist (I also created shortcuts to the front-end users locations):

Then I Run the shortcut:

Now I have changed the color of a button of my database form (.accdb file) on my Local Disk (D

Now I save as and replace my ACCDE file in my Local Disk (D

But No changes are updated on a single distributed FE files, I've checked the file on the users computers and server as well:
Screenshot of FE file from users desktop:

I've tried to open the updater again and again. But nothing is updating on users' front-end files. Until I copy the updated ACCDE file from my Local Disk to the server and users' desktops manually.

 

[Khurramshaikh47]

The .bat file needs to be stored on the server. You can place it in the directory where the master copy of the FE is stored. Do NOT store the .bat file in the user directory. You seem to have swapped the .bat file with the shortcut. The shortcut is installed on the LOCAL drive. The .bat file lives on the Server so that if you need to change it, you can change it without having to visit every single user computer!!! The shortcut simply runs the .bat file so it would never need to change.

Did you send a copy of the shortcut that opens the .bat file to each user?

Developers should ALWAYS have extensions displayed. You should never have to guess what the extension is for any file.

Ok Pat now I will show the extension of my files.
Actually I have saved the master copy of FE on my local disk and copy it to the server. You mean I have to save the .bat file to the server and then share its shortcut to my local disk and to the users as well?

 

[Khurramshaikh47]

Thanks for the like but we are not children here. Likes are totally useless when it comes to helping people who find this thread later determine what answer solved the problem. So, when you have a solution to a problem it is always more helpful to say, in words, what it was or if one specific comment helped more than others, point that out.

I am sorry I was reading your reply and understanding it.

 

[gemma-the-husky]

Updating programme versions is a tricky thing.

fwiw, I use a UK government payroll (free for small companies). Download and install. When they release a new version, the software asks you whether you want to install the new version. If you accept, it closes your current payroll, and downloads an updater to make the required changes. It's still not clever enough to tell you when it's done, and then restart the service. You have to guess it's probably finished and restart it yourself. And that's the government! (well, the UK Inland Revenue Service).

So my updater is a bit like that. Does 95% of it, but you still have to do a bit yourself, and I find it's hard to rely on users understanding anything about computers. A lot of them don't understand a folder structure, for instance. They often don't realise their file extensions are hidden for known file types, so can't tell the difference between a database file, and a locking file, and could easily delete the database file. They try searching for the database, and find the master copy on the server, which fortunately won't work because there are no configuration files in that folder on the server, but they phone for support because of the errors, and you wonder what made them not follow the simple instructions.

They might not show full details of files in their file explorer (if they understand what you mean by file explorer), so they can't even tell you there's a big one and a small one. (database file and locking file). You would think Access would be able to prevent users accidentally deleting or even messing with the back end, wouldn't you, but I always have it in mind that a user might just delete the back end.

Sorry, we are a fair way away from the thread title, and I'm just letting off a little steam.

 

[Khurramshaikh47]

Not sure why this is so hard. Again.
1. The current distribution version of the FE is stored on the server. Unless your PC is properly backed up, then you need to also store your design master on the server. It is too dangerous to have the design master stored only on your Local PC.
2. The BE is stored only on the server. You need a testing copy and that should be stored on your local PC.
3. The .bat file is stored on the server.
4. The master copy of the shortcut is stored on the server.
5. Create a shortcut that runs the batch file. Store it on the server
6. You distribute the shortcut to each person who will be using the application with instructions to save it on their local drive (not sure why you are using D (something is amiss here). The local drive is always C. Use email to distribute the shortcut.

When the user wants to run the application, he double clicks on the shortcut.
The shortcut runs the batch file from its server location
The batch file executes the four instructions.
The FE opens on the client PC.

YOU are the developer. Are you also a USER of the application? If so, then you also need the shortcut when you want to open the production version of the application. When you want to work on your development version, you open it directly. You would NOT EVER use the shortcut since the shortcut would overwrite your changes and you would be very unhappy.

Thank you so much Pat, It's working perfectly.

 

[Babycat]

Not sure why this is so hard. Again.
1. The current distribution version of the FE is stored on the server. Unless your PC is properly backed up, then you need to also store your design master on the server. It is too dangerous to have the design master stored only on your Local PC.
2. The BE is stored only on the server. You need a testing copy and that should be stored on your local PC.
3. The .bat file is stored on the server.
4. The master copy of the shortcut is stored on the server.
5. Create a shortcut that runs the batch file. Store it on the server
6. You distribute the shortcut to each person who will be using the application with instructions to save it on their local drive (not sure why you are using D (something is amiss here). The local drive is always C. Use email to distribute the shortcut.

When the user wants to run the application, he double clicks on the shortcut.
The shortcut runs the batch file from its server location
The batch file executes the four instructions.
The FE opens on the client PC.

Hi Pat,

I distribute same FE to 2 different teams: R&D and purchasing team. They have to login in with given username & password, this login form has "remember me" feature which is store on local table.
If the FE is downloaded from server everytime user clicking on the shortcut, then"remember me" feature will no longer work.

Is there a good suggestion for this circumstance?

Thank you

 

[Minty]

@Babycat - You could store those details in a local text file, and check its existence in the login process.
Not terribly secure but if they have logged in before then does it matter?

 

[isladogs]

Maybe I'm being dense but why can't that login data be stored in a BE table, preferably with the passwords encrypted

 

[Babycat]

@Babycat - You could store those details in a local text file, and check its existence in the login process.
Not terribly secure but if they have logged in before then does it matter?

Kind of lazy to handle an extra text file, many thing can be happened with that file which is outside of Access db

 

[Babycat]

Maybe I'm being dense but why can't that login data be stored in a BE table, preferably with the passwords encrypted

Hi Isladogs,

Same FE file is downloaded from server to local (user's) computer everytime user start the application, thus how and where to store these login data?

 

[isladogs]

As I said. why not in the BE

 

[Babycat]

As I said. why not in the BE

Not so clear what you mean, but the case is user selecting "remember me" on login form for the 1st login, next time they will not need to type username & password again.
This looks impossible if a fresh new FE is downloaded from server...

 

[isladogs]

Add a Boolean field to store the Remember Me value in the users table in the BE.
When the user first ticks that box, the value is set to True jn the table.

I use the same approach to store user preferences like Don't Show This Help Form again based on a checkbox each user can tick.

Having said all that, its not at all secure if you allow users to bypass the login process.
You may as well have no login process at all

 

[Babycat]

The fresh FE gives no clue to indentify the user opening FE... that is the point, sir

 

[isladogs]

I thought you were using the network user login name in which case it would apply.
Either way, you should not be allowing users to bypass the login process