Re: Linking in Access
- From: "Jeff Boyce" <nonsense@xxxxxxxxxxxx>
- Date: Mon, 23 Apr 2007 07:51:09 -0700
Another approach to consider would be to create the front-end, with your
queries, forms, reports, then convert it to an .MDE file. This would remove
the user's ability to modify the front-end.
Regards
Jeff Boyce
Microsoft Office/Access MVP
<aliya.hussain@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1177326831.518095.43740@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 20 Apr, 18:55, "Jeff Boyce" <nonse...@xxxxxxxxxxxx> wrote:
Aliya
see comments in-line below...
Thanks for a prompt reply. No I haven't split the DB as then I will
have to give access to the queries and reports.
I don't understand. Why would splitting the DB give them any more access
to
queries/reports than they would have if the DB were not split?
If they can have a
form with buttons to click, maybe in a diff DB (diff forms for diff
depts e.g., safety, employment, production, DTP, etc) which drive the
reports based on queries (both stored in my/main DB).
Or you could use a single form, but have it appear different, or simply
only
display relevant choices, depending on the logon of the person using it.
If
you want a simpler approach, you could create a table that connects each
person's logon to their department, so your form would "know" which set
of
data to show.
I don't know
whether this would be called as read only access.
To make a form read-only, you can set the properties to dis-allow edits.
Or
you could set the query's property to return only a snapshot, not an
updateable dataset.
But in this way
there will be no fear of any interefernce in my queries, tables and
reports.
Does this mean you wish the users not to touch your queries, tables,
reports? One way to accomplish this would be to give them a form to use,
and to have the form shut down the application if they try to exit the
form.
However, a really determined person will still find a way. Are you
concerned about absolute security (if so, start looking into SQL-Server),
or
simply preventing casual/accidental changes?
The form is to be linked to the main DB.
And yes everyone is on the same network environment, have a username-
password to login and work for only one dept.
That means you'd be able to create a table that shows that relationship.
You'd need to keep it maintained as folks came/went. The table could
live
in the back-end, and be hidden from the user's view.
Regards
Jeff Boyce
Microsoft Office/Access MVP
Morning Jeff
Yes I am concerned about the security to a certain extent but mainly
trying to prevent any casual/accidental changes. If there is any
problem in future it could become difficult to trace it back if there
are too many users handling the complete DB.
They need an easy way to get their info and I could think of only
buttons on a form which I have already created.
Initially there were only 2 depts requiring the info and hence they
have been given access (only relevant people). But the number of depts
requiring info is now increasing as things are progressing and I am a
little sceptical about giving access to all.
Splitting would give them access to queries and reports besides the
forms. Also I cannot set the editing property of the forms to be in
editable as then the users would not be able to use the drop down
lists on the forms.
You said "One way to accomplish this would be to give them a form to
use, and to have the form shut down the application if they try to
exit the form." Does this mean that in their DB they have only the
form. If yes how can I link this form to the rpts and the qrys
attached to it= which will be in the main DB.
Also how would I go about it.
Thanks
Aliya
.
- References:
- Linking in Access
- From: aliya . hussain
- Re: Linking in Access
- From: Jeff Boyce
- Re: Linking in Access
- From: aliya . hussain
- Re: Linking in Access
- From: Jeff Boyce
- Re: Linking in Access
- From: aliya . hussain
- Linking in Access
- Prev by Date: Re: Openning Access at control panes
- Next by Date: Re: Passing Variables what am I doing wrong?
- Previous by thread: Re: Linking in Access
- Next by thread: Re: invalid syntax
- Index(es):