i need help with the attached Data Base plz .

[Ossama22]

Hello ,

I Have this data base i need help with some VB codes , i wanna to lock or ( make the Account number cell dimmed) while the clearance code = any value expect the default blank value for sure . any one can help with that plz .


Another ask , we r 9 ppl gonna use this data base , is there any "simple" and not complicated ways to let the other 8 persons to log as a users only ( read only mode not to modify any data ) and only me who gonan be the admin , is that possible in access like excel , (Password for readonly mode , and password for read & write mode)
Thx guys

The data base is attached View attachment Database.zip

 

[The_Doc_Man]

You have asked the question before about having limited access to 8 users and full access to a ninth user. You were given references to look up. The problem is quite complex and I understand it might be daunting. However, many versions ago, Access stopped honoring user-level security settings. Now you have to build in your own security by putting up your own barricades to keep people out.

There are no SIMPLE answers to this problem that don't multiply your work by a lot. Sometimes when you want to do something complex and selective, there is no simple answer. Only complex answers.

You can either read the articles about securing the database OR you can maintain two copies of the front end and have copy with everything set to .AllowEdit = NO, .AllowDelete=NO, etc. etc. - essentially, double the work if you have to ever make an update. AND the copy you give to the 8 read-only users would probably best be compiled and saved as an .ACCDE or .MDE file as appropriate for your app so that they can't reach in and override your .Allow settings.

 

[Pat Hartman]

If you can switch the BE from Jet/ACE to SQL Server, the solution is actually trivial. You can use SQL Server credentials to control who can update what and won't have to implement the locking with code in forms.

 

[Ossama22]

You have asked the question before about having limited access to 8 users and full access to a ninth user. You were given references to look up. The problem is quite complex and I understand it might be daunting. However, many versions ago, Access stopped honoring user-level security settings. Now you have to build in your own security by putting up your own barricades to keep people out.

There are no SIMPLE answers to this problem that don't multiply your work by a lot. Sometimes when you want to do something complex and selective, there is no simple answer. Only complex answers.

You can either read the articles about securing the database OR you can maintain two copies of the front end and have copy with everything set to .AllowEdit = NO, .AllowDelete=NO, etc. etc. - essentially, double the work if you have to ever make an update. AND the copy you give to the 8 read-only users would probably best be compiled and saved as an .ACCDE or .MDE file as appropriate for your app so that they can't reach in and override your .Allow settings.

Hello bro ,
Iam sorry for repeating my question but as i said before iam still beginner with access , thats why i faced alot of difficulties when i watched videos about users and admin , its kinda complicated to me , but i will try to do that

And can u help about my sexond question , related to vb codes and lock the cell ?

 

[arnelgp]

here try this.
this is ine time password set up only.
next time you oprn the payroll form it will ask for password.
invalid pass or ignoring the ligin form will result to non editable form.

 

[The_Doc_Man]

You cannot lock ANYTHING in Access unless you write code within the app to disallow the person from making changes. Which is actually my point about reading through some of the articles on securing a database.

I actually DO understand that it is tough for a beginner. It is NOT a simple task. I recall how long it took me to get everything more or less right when I had to secure my database to recognize different roles.

If my answer seemed abrupt, please forgive me for being a bit blunt; I try to tell stuff like it is and not sugar-coat it, but that sometimes comes across as being unsympathetic. The sad truth is that Access and Excel take two VERY DIFFERENT approaches to data management. Things that are simple in one are difficult in the other, and that goes both ways. Locking of records and/or fields is one such issue where they are worlds apart.

If you are a beginner then Access at the VBA level CAN be daunting. No... it IS daunting. The learning curve is very steep because it requires you to think differently. And as you are finding out, the more complex a task ahead of you, the harder it is to "wrap your head around it."

The only solution I have found is to read multiple articles and see if you can piece together a coherent (or at least, usable) image of what has to be done. I see only two solutions to your problem.

Given the level of expertise that you claim, the EASIER method might be to build your app with a switchboard form for the maintainer to use. Then make a COPY of that in which all the forms are set with the .AllowEdit and .AllowDelete and the other relevant form properties set to "NO" - to disallow at form level all those things you don't want done. Now do the things to secure that front-end like disabling the SHIFT key and blocking the right-click menus and such. Convert it to an .ACCDE or .MDE as appropriate to the version of Access you are using.

The COST of this method is that every time you need to make changes to your system, you have to make them first to the admin user copy and then repeat the process of making the restricted copy. This is a very high overhead cost (in terms of handling the copies) for you to perform maintenance but a low price in terms of the VBA you would have to write. Given your disclaimer of comfort with VBA, this might be the easier solution.

LONG TERM you will get very tired of this. The correct solution is to build in "smarts" on each form so that they can decide at Form_Load time whether to set the .Allow properties of the form to YES or NO. But that requires a user table and some behind-the-scenes infrastructure on each form, and involves a lot of VBA coding.

I hope that this gives you the perspective you need. Please don't take my comments as in ANY way trying to dismiss you callously. Just understand that I am sometimes a bit direct so that I can give shorter answers - and thus make more of them to more forum members.