Re: Relink question

It's not ULS that's the impenetrable thicket, it's the documentation. ULS is a bit difficult to follow at first (Jack MacDonald's paper of the subject was the one that finally led me to understand what is going on), but the FAQ is helpful only after the subject has been learned elsewhere. I still think they could have updated the FAQ at least to include Access 2003 in the title.

I think I have found enough clues in the documentation to deduce that the destination database is the FE and the source database is the BE. Section 14.3 states that the Connect property can be used as long as there are "full permissions in the destination (FE) database and Open/Run permissions on the source database (BE) - no permissions at all are necessary on the source tables." Assuming this literally referes to database permissions rather permissions to any tables, queries, etc., it either says that there are no security implications to granting all users full permissions to the FE database, or that I would need to use the code in the faq_SetPermissions function to change permissions temporarily. However, the documentation for that function "assumes that a member of the Admins group will be executing the code". I'm not sure why it assumes that, since the group name apparentlly is passed to the function, but assuming it is necessary to pass the Admins group name, either the code can be run only by members of the Admins group or everybody needs to be a member of the group. If membership in the Admins group is necessary to run the code either everybody needs to be a member of the Admins group (which pretty much wipes out security), or only a few users can relink tables. Or maybe the faq_SetPermissions function is not necessary. In any case, it seems that using the Connect property is possible

I could be mistaken about the meaning of "source" and "destination". The source could be the origin of data (FE) that flows to the destination (BE), or the source could be the collection of data (BE) that flows to the destination where it will be seen and used (the FE). Figurative language should be defined. Maybe I'm supposed to know the meaning of the two terms, but I have not found a way to frame the search question. If I had to bet I would say the source is the BE.

For now users will get an error message if the table link is not successfully refreshed, and I will fix it. This has not happened, so maybe I will continue to be lucky for a while longer. Beyond that maybe I can use the code at the mvps web site (RefreshLink), modified to remove some or all of the prompts. Maybe I can combine it with an ini file that lists the path.

Beyond that I don't have a prayer, at least not until I have a few more years experience behind me. I am extremely frustrated by my inability to sort this out, but at least I am old enough that I know when to admit I am beaten. Thanks for trying to help. I really do appreciate the time you have put into your responses.

"Graham Mandeno" <Graham.Mandeno@xxxxxxxxxxxxx> wrote in message news:E019493E-A1FE-46CC-842F-5C60C1C464BA@xxxxxxxxxxxxxxxx
Hi Bruce

The method I use (and would recommend) is the one in 14.3, because it *always* works, no matter what the permissions on the backend tables.

Note that allowing all permissions on the linked tables in the frontend does not grant permissions to the *data*. It just allows the user to delete and relink the tables.

Yes, you're right, user-level security can seem like an "impenetrable thicket", but if properly implemented it works well and is sufficiently secure for most applications. I am one among many who are very disappointed that it has been canned in A2007.
--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand

"BruceM" <bamoob@xxxxxxxxxxxxxxxx> wrote in message news:eYgtJF$SJHA.5268@xxxxxxxxxxxxxxxxxxxxxxx
I have full permissions for all users on the BE tables, and table permissions restricted in the FE depending on the group. The Users group has no permissions anywhere. I think that means some variant of the code in 14.1 of the FAQ would work (which seems to be the same general idea as the code at the mvps web site, I think).

I have to say I marvel anew at the Security FAQ each time I see it. It is an almost inpenetrable thicket, further impeded by instructions and information going back to Access 2.0.

Since I do not have RWOP queries I think I can use RefreshLink. The FAQ states:
"The best way to implement this [it is not clear in context to what "this" refers; maybe it means restricting access to the data, or maybe RWOP] is to remove ALL permissions from the underlying table(s) and use only queries to get at the data you want your users to have."
But later is seems to suggest that full permissions can be assigned to the tables in the destination database. It would help if I knew whether the destination database is the link's destination (i.e. the BE) or if "destination" means something else.

Anyhow, I have not found a need for RWOP queries, so I think I'm OK with RefreshLink. If I have a problem that could be solved through the use of RWOP queries I have not been able to identify that a RWOP query is what I need. I think Joan Wild has some more information about this on her web site. Yet another thing to sort out.

I do appreciate your pointing this out. I have to say, though, that it will take a lot of development time I do not have right now to sort out how to read the correct path from an ini file or somewhere, check the existing link against that, and refresh the link if need be. For now the users will get an error message, and I will fix it. I wish there was another way, but a better solution will have to wait.

"Graham Mandeno" <Graham.Mandeno@xxxxxxxxxxxxx> wrote in message news:A66CBCB9-26A2-4784-A941-8086AD04AF0D@xxxxxxxxxxxxxxxx
Hi Bruce

Finally, if you use user-level security then I recommend you read the section on linked tables (section 14) in the Access Security FAQ:
http://support.microsoft.com/support/access/content/secfaq.asp

--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand

"BruceM" <bamoob@xxxxxxxxxxxxxxxx> wrote in message news:u0vgJpwSJHA.5056@xxxxxxxxxxxxxxxxxxxxxxx
I declare every variable. I have chosen Option Explicit as the default option, so Access won't let me implicitly declare. It has been a great help with debugging.

I didn't know that about using an extension other that mdb for BE files. ABE is not a registered file type on my machine, so I suppose that means I would need to add it. I use user-level security for my split databases (which is all of my newer ones), so a user who attempts to open the file, either FE or BE, by double clicking the icon will receive a message about insufficient permissions. The only way in is through a shortcut that temporarily joins the user to the secure workgroup file.

Thanks again for the information. This is an area of Access with which I have had little experience, due in large part to a lack of information. I have lots of information now, so I can work on gaining experience.

"Graham Mandeno" <Graham.Mandeno@xxxxxxxxxxxxx> wrote in message news:OTS5XKpSJHA.1908@xxxxxxxxxxxxxxxxxxxxxxx
Hi Bruce

Yes, you should Dim dbBE as DAO.Database. (It could be declared as Object, but every database should have a reference to DAO anyway, so early binding is faster and gives better compile-time checking.) In any case, it will need to be declared.

BTW, EVERY variable you use should be declared. using implicit declaration is asking for trouble. EVERY module, including Form and Report modules should have Option Explicit at the top.

The path to the backend is just that - the full file path - for example:
"\\MyServer\SomeShare\My App Folder\Back-end file.mdb"

BTW, there is no law that says an Access database must have the extension "MDB". All my backends are .ABE files (Access Back-End). It at least discourages users from double-clicking on them to open them!


--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand

"BruceM" <bamoob@xxxxxxxxxxxxxxxx> wrote in message news:OiysMhoSJHA.5900@xxxxxxxxxxxxxxxxxxxxxxx
I'll give that a try when I have a chance to get back to it, which may not be tomorrow. Two more questions for now: Is there any need to made the dbBE variable a DAO.Database? And is the path to the back end a path first to the Access executable, followed by a switch that includes the path to the BE (like with decompile, etc.), or is it just a direct path to the BE file?

BTW, I don't think I have a project so far with more than maybe 20 tables in a single BE database.









.

Relevant Pages

  • Re: Advanced Security Issue
    ... > SuperUser, who has no permissions, but is a member of the Admins group which ... > capable of modifying permissions on the database. ... I discovered that if I recreate the SuperUser with my RemoteUser ... > inherited them through the Admins group, ...
    (microsoft.public.access.security)
  • Re: Relink question
    ... You're also correct about the FAQ being a difficult document to grasp. ... have Open/Run permissions on the backend (which they would need to read the ... destination database is the FE and the source database is the BE. ... Admins group will be executing the code". ...
    (microsoft.public.access.formscoding)
  • Re: User has group permissions to object, but still denied access.
    ... specific queries is identical to queries that she does have the ability to ... permissions depending on where the file is, it means she's either opening the ... about 80 queries in the database, and I haven't been able to find a pattern ... The Admins group was given full permissions. ...
    (microsoft.public.access.security)
  • Re: Module level security
    ... Start the database using a shortcut of the following format - all on one ... Log-on as a member of the Admins group. ... Use the Tools:Security interface to grant all necessary permissions to ... specific workgroup file, will be able to do what you want. ...
    (microsoft.public.access.security)
  • Advanced Security Issue
    ... SuperUser, who has no permissions, but is a member of the Admins group which ... capable of modifying permissions on the database. ... I discovered that if I recreate the SuperUser with my RemoteUser ... and only inherited them through the Admins group, ...
    (microsoft.public.access.security)