Linked table issues (1 Viewer)

Ossama22

Registered User.
Local time
Today, 17:22
Joined
Aug 31, 2018
Messages
52
Hey guys,
I have a simple question,
Can i link a linked table to database,
To be more specific, i have a db named (data), i linked it to another db named (linked 1), i wanna to link (linked 1) to the third db (salaries),
So is there any way to do that?
 

isladogs

MVP / VIP
Local time
Today, 15:22
Joined
Jan 14, 2017
Messages
18,186
Link it from the original database (data?) or import it from the second database
 

Ossama22

Registered User.
Local time
Today, 17:22
Joined
Aug 31, 2018
Messages
52
Link it from the original database (data?) or import it from the second database

I dont want to link from data to salaries, cuz i wanna the data from (data) be protected, by another me the salaries user not be able to data from (data) db
I think u named it back end or front end smth like that
 

theDBguy

I’m here to help
Staff member
Local time
Today, 08:22
Joined
Oct 29, 2018
Messages
21,358
I dont want to link from data to salaries, cuz i wanna the data from (data) be protected, by another me the salaries user not be able to data from (data) db
I think u named it back end or front end smth like that
Hi. In short, you can't. When you link the third db to the second one which is link to the first one, Access will automatically link the third db to the first one, where the data is. Besides, if you want to protect the data, then don't give users access to it, even by linking. If that can't be helped, then you could consider moving your data to SQL Server where you can create "read only" links.
 

Ossama22

Registered User.
Local time
Today, 17:22
Joined
Aug 31, 2018
Messages
52
Hi. In short, you can't. When you link the third db to the second one which is link to the first one, Access will automatically link the third db to the first one, where the data is. Besides, if you want to protect the data, then don't give users access to it, even by linking. If that can't be helped, then you could consider moving your data to SQL Server where you can create "read only" links.

Could you tell me how to protect db from clicking?
 

isladogs

MVP / VIP
Local time
Today, 15:22
Joined
Jan 14, 2017
Messages
18,186
You can open a database read only using the /ro switch.
Doing that means nothing can be edited but there are very few situations where that makes sense.
End users should never have direct access to tables. Hiding the navigation pane is very easy to do.
All interaction should be via forms which can easily be made read only by locking the form.
 

theDBguy

I’m here to help
Staff member
Local time
Today, 08:22
Joined
Oct 29, 2018
Messages
21,358
Could you tell me how to protect db from clicking?
You could also set the permission to the folder to Traverse only, so users can't click on it.
 

isladogs

MVP / VIP
Local time
Today, 15:22
Joined
Jan 14, 2017
Messages
18,186
You could also set the permission to the folder to Traverse only, so users can't click on it.

Might be worth explaining that in more detail with reference to the folder permissions options
 

theDBguy

I’m here to help
Staff member
Local time
Today, 08:22
Joined
Oct 29, 2018
Messages
21,358
Might be worth explaining that in more detail with reference to the folder permissions options
Hi. I'm certainly no expert on Windows permissions, but I guess I could give it a try. So, let's say you have the BE file placed in a folder called \\ServerName\MainFolder\DBFolder\DataFolder
We know the users must have "full" permission to DataFolder. But that would mean users will be able to navigate/view DataFolder and see a list of files in that folder, which they could then double-click to open. To prevent that, we could try setting the permission to this folder as follows:





Some explanations of what each permission does is available here. Hope this helps...


Note: I haven't tested the above, so I am not 100% sure it's all that's needed to prevent the users from double-clicking on a file.
 

Attachments

  • permission.PNG
    permission.PNG
    56.6 KB · Views: 170
Last edited:

isladogs

MVP / VIP
Local time
Today, 15:22
Joined
Jan 14, 2017
Messages
18,186
Just to add that the previous screenshot is from the advanced permissions screen. The basic permissions doesn't include several items listed including the traverse option
 

Attachments

  • Basic permission options.PNG
    Basic permission options.PNG
    15.1 KB · Views: 68
  • Advanced permissions.PNG
    Advanced permissions.PNG
    19.6 KB · Views: 78

Mark_

Longboard on the internet
Local time
Today, 08:22
Joined
Sep 12, 2017
Messages
2,111
Rather than trying to keep them from accessing "Data", I would move any tables that users should not update to its own "Config" database. You would code "Config" to have your tables that should not be changed. "Config" connects in to "Data" and checks the tables that should not change. If any are changed, Config updates them to what they should be.

This does REQUIRE you to have a separate computer that only runs "Config" and does it all of the time. I would only have it check once every 30 seconds or so though, so it doesn't have a major impact on your operations.

"Config" could also log any time it does have to update your "Data" back end. This gives you a log of when corrections are made, thus helping you identify who is doing things they should not be.
 

The_Doc_Man

Immoderate Moderator
Staff member
Local time
Today, 10:22
Joined
Feb 28, 2001
Messages
26,999
I've got a CompTIA Security+ certificate and a couple of certifications from the U.S. Navy from when they sponsored Windows security classes (before going commercial with it). Here is what you need.

Look at colin's two presentations - "basic" and "advanced" permissions. I will refer to them for the permission names.

1. To get to the folder where the DB app files are located, you must have EITHER "list files/read data" or "traverse folders/execute file" (advanced) or "READ" (basic) on every folder above the DB file's "home" folder EXPLICITLY INCLUDING the root folder of the drive. No exceptions. Now, normally the root folder is set for "list files/read data" for all "authenticated users" (at least). In a lax environment, that might be for "EVERYONE" which is a different group than "authenticated users."

2. To use the DB file normally, you need a complex of advanced permissions, but the EASIEST way to assure you have what you need is to have MODIFY (basic) on the folder AND all files therein, including the DB files.

What comes with MODIFY is that you gain read data/list files on the folder, but you ALSO gain create file/write data and delete file on the folder, which you need because of the lock file. The rule (and the reason you need create/delete on the folder) is that the first person to open the DB file for the day also creates the lock file, and the last person to close the DB file for the day also deletes the lock file. Obviously, the ability to do updates on the DB files comes from the "write data" permission.

3. Special case: If you only have READ on the folder, regardless of what permissions you might have on the DB files, you open that file read-only anyway because you can neither create nor modify (add yourself to) the lock file. If Access cannot manage the lock file then you are in read-only mode. NOTE however, that if you enter the file in read-only mode for this reason, you might actually block other users coming in after you because there is still a WINDOWS file lock involved and you opened the DB in read-only mode. That can screw the pooch on sharing big time.

4. On a PC workstation hosting the FE files, the person logging in on that workstation normally has FULL CONTROL (basic) in low-security domains or MODIFY (basic) in domains with more stringent security. On your home PC, you are usually the "owner" and thus have FULL CONTROL (basic).

5. In a domain environment, there are several strategies but for corporate or departmental databases, particularly if the IT Security team has their way, would be to create a group name (like "FiscalDBUsers") and assign permissions according to the group name. Then add members to the group as needed. I.e. never (well... hardly ever) add individual permissions on a project DB. Instead, add a project's group name to the domain, assign permissions (once) to the group, and then assign users to be members of the group. Mechanically, this is INCREDIBLY better than going in and dinking around with basic or advanced permissions per person, particularly if the folder isn't logically very near to the drive's root folder. (I.e. many-folder path, deep path, many-step path, whatever other way you say it in your neck of the woods.)

6. Finally, the reason the BASIC permissions list is shorter is because when you check one item on BASIC, you find that you have implicitly checked as many as six or seven items on ADVANCED. Think of the BASIC permissions as similar to macro settings that imply multiple elements in a single click.
 

Users who are viewing this thread

Top Bottom