Re: Relink question

Hi Bruce

You're correct about "source" and "destination". Source is where you are
linking *from* (backend) and destination is where you are linking *to*
(frontend).

You're also correct about the FAQ being a difficult document to grasp. In
its defence, it covers a lot of information about a very complex area, but
it was also written by quite a number of people over a number of years and
versions, and it would definitely benefit from a rewrite. For a start, I
doubt anyone is interested in the Access 2.0 bits any more! Unfortunately,
since ULS is the baby that MS has thrown out with the bathwater, putting
resources into a rewrite is unlikely :-(

Basically, any user who may relink tables (and for me this means any user
who may open the frontend) should have all permissions to <New
tables/queries> in the frontend (see section 16.3). Then, provided they
have Open/Run permissions on the backend (which they would need to read the
data anyway), they can link tables using the delete-and-recreate-TableDef
method (section 14.3).

Sorry if you already told me, but how did you get on with reading/writing
the INI file?

--
Good Luck :-)

Graham Mandeno [Access MVP]
Auckland, New Zealand

"BruceM" <bamoob@xxxxxxxxxxxxxxxx> wrote in message
news:OHbbUajTJHA.5860@xxxxxxxxxxxxxxxxxxxxxxx
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: Relink question
    ... 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 database and Open/Run permissions on the source database - no permissions at all are necessary on the source tables." ... 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. ...
    (microsoft.public.access.formscoding)
  • 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: 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)
  • 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)
  • RE: Question re: Admins Group
    ... Members of the Admins group have special permissions, ... whereas a user joined to Admins group can. ... Members of the Admins group have built-in permissions that one cannot assign ... See http://www.QBuilt.com for all your database needs. ...
    (microsoft.public.access.security)
Loading