How to make all access to linked table read-only

[Bob Alston]

Anyone know a way to make all access to a linked table, in another
Access MDB, read only?

I really don't want all the hassle of implementing full access security.

I can't do this at the server file system because in some front ends the
user needs update access.

I want to give users access to the data for reporting with their own
queries and reports. I just don't want to take a chance on them
updating the data via such tools.

Bob

[Wayne Morgan]

While this won't stop them if they get access to the database window, you
could make the queries "Snapshots" . Snapshots are read only and any
subsequent object based on that query will also be read only for data that
comes from that query. Also, reports aren't a problem, there is no editing
data that the user can do in a report. The problem would come it if you give
them access to a form or query (or the table itself) that is read/write.

--
Wayne Morgan
MS Access MVP
"Bob Alston" <tu************ ****@cox.net> wrote in message
news:W%dGe.5357 5$4o.43523@fed1 read06...

Anyone know a way to make all access to a linked table, in another Access
MDB, read only?

I really don't want all the hassle of implementing full access security.

I can't do this at the server file system because in some front ends the
user needs update access.

I want to give users access to the data for reporting with their own
queries and reports. I just don't want to take a chance on them updating
the data via such tools.

Bob

[Bob Alston]

Wayne Morgan wrote:

While this won't stop them if they get access to the database window, you
could make the queries "Snapshots" . Snapshots are read only and any
subsequent object based on that query will also be read only for data that
comes from that query. Also, reports aren't a problem, there is no editing
data that the user can do in a report. The problem would come it if you give
them access to a form or query (or the table itself) that is read/write.

GREAT.

In the interim read about a way to relate the table to a table in a
read-only db and use the resultant query.

Your's is cleaner. And I understand I can hide the linked table entry
(but not sure how to unhide it to see it again).

Bob

[Bob Alston]

Bob Alston wrote:

Wayne Morgan wrote:

While this won't stop them if they get access to the database window,
you could make the queries "Snapshots" . Snapshots are read only and
any subsequent object based on that query will also be read only for
data that comes from that query. Also, reports aren't a problem, there
is no editing data that the user can do in a report. The problem would
come it if you give them access to a form or query (or the table
itself) that is read/write.

GREAT.

In the interim read about a way to relate the table to a table in a
read-only db and use the resultant query.

Your's is cleaner. And I understand I can hide the linked table entry
(but not sure how to unhide it to see it again).

Bob

OK but how do I specify that a query is to be/produce a snapshot instead
of a dynaset?

Bob

[Bob Alston]

Bob Alston wrote:

Wayne Morgan wrote:

While this won't stop them if they get access to the database window,
you could make the queries "Snapshots" . Snapshots are read only and
any subsequent object based on that query will also be read only for
data that comes from that query. Also, reports aren't a problem, there
is no editing data that the user can do in a report. The problem would
come it if you give them access to a form or query (or the table
itself) that is read/write.

GREAT.

In the interim read about a way to relate the table to a table in a
read-only db and use the resultant query.

Your's is cleaner. And I understand I can hide the linked table entry
(but not sure how to unhide it to see it again).

Bob

I trust you didn't mean create a snapshot of the data via using a
make-table query!!!! Ugly.

Bob

[David W. Fenton]

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:Oy******** *******@newssvr 25.news.prodigy .net:

While this won't stop them if they get access to the database
window, you could make the queries "Snapshots" . Snapshots are read
only and any subsequent object based on that query will also be
read only for data that comes from that query. Also, reports
aren't a problem, there is no editing data that the user can do in
a report. The problem would come it if you give them access to a
form or query (or the table itself) that is read/write.

Why not skip linked tables and assign the recordsources using
connect strings, like:

SELECT ...
FROM MyTable IN '\\Server\datab ases\Data.mdb'
WHERE ...

Then set the recordset type for the form to SNAPSHOT.

Again, absent user-level security, the end user could still change
the recordsource and the recordset type property at runtime, but
this would surely slow them down substantially.

The other advantage of this is that you could alter the recordset
type property at runtime according to who the user is, so that you
wouldn't have to have completely different front ends for the
read-only and editing-allowed users.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc

[Bob Alston]

David W. Fenton wrote:

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:Oy******** *******@newssvr 25.news.prodigy .net:

While this won't stop them if they get access to the database
window, you could make the queries "Snapshots" . Snapshots are read
only and any subsequent object based on that query will also be
read only for data that comes from that query. Also, reports
aren't a problem, there is no editing data that the user can do in
a report. The problem would come it if you give them access to a
form or query (or the table itself) that is read/write.

Why not skip linked tables and assign the recordsources using
connect strings, like:

SELECT ...
FROM MyTable IN '\\Server\datab ases\Data.mdb'
WHERE ...

Then set the recordset type for the form to SNAPSHOT.

Again, absent user-level security, the end user could still change
the recordsource and the recordset type property at runtime, but
this would surely slow them down substantially.

The other advantage of this is that you could alter the recordset
type property at runtime according to who the user is, so that you
wouldn't have to have completely different front ends for the
read-only and editing-allowed users.

I don't want to use a form. I suspect the users will work from queries,
do cross tabulations and occasionally reports. So I really need to
protect the table or hide the table and protect the underlying query.

Bob

[Br]

Bob Alston <tu************ ****@cox.net> wrote:

David W. Fenton wrote:

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:Oy******** *******@newssvr 25.news.prodigy .net:

While this won't stop them if they get access to the database
window, you could make the queries "Snapshots" . Snapshots are read
only and any subsequent object based on that query will also be
read only for data that comes from that query. Also, reports
aren't a problem, there is no editing data that the user can do in
a report. The problem would come it if you give them access to a
form or query (or the table itself) that is read/write.

Why not skip linked tables and assign the recordsources using
connect strings, like:

SELECT ...
FROM MyTable IN '\\Server\datab ases\Data.mdb'
WHERE ...

Then set the recordset type for the form to SNAPSHOT.

Again, absent user-level security, the end user could still change
the recordsource and the recordset type property at runtime, but
this would surely slow them down substantially.

The other advantage of this is that you could alter the recordset
type property at runtime according to who the user is, so that you
wouldn't have to have completely different front ends for the
read-only and editing-allowed users.

I don't want to use a form. I suspect the users will work from
queries, do cross tabulations and occasionally reports. So I really
need to protect the table or hide the table and protect the
underlying query.
Bob

By now you could have easily setup jet security to limit write access to
your tables. It's there for a reason so why not use it?
--
regards,

Bradley

A Christian Response
http://www.pastornet.net.au/response

[Bob Alston]

Br@dley wrote:

Bob Alston <tu************ ****@cox.net> wrote:

David W. Fenton wrote:

"Wayne Morgan" <co************ *************** @hotmail.com> wrote in
news:Oy***** **********@news svr25.news.prod igy.net:

While this won't stop them if they get access to the database
window, you could make the queries "Snapshots" . Snapshots are read
only and any subsequent object based on that query will also be
read only for data that comes from that query. Also, reports
aren't a problem, there is no editing data that the user can do in
a report. The problem would come it if you give them access to a
form or query (or the table itself) that is read/write.
Why not skip linked tables and assign the recordsources using
connect strings, like:

SELECT ...
FROM MyTable IN '\\Server\datab ases\Data.mdb'
WHERE ...

Then set the recordset type for the form to SNAPSHOT.

Again, absent user-level security, the end user could still change
the recordsource and the recordset type property at runtime, but
this would surely slow them down substantially.

The other advantage of this is that you could alter the recordset
type property at runtime according to who the user is, so that you
wouldn't have to have completely different front ends for the
read-only and editing-allowed users.

I don't want to use a form. I suspect the users will work from
queries, do cross tabulations and occasionally reports. So I really
need to protect the table or hide the table and protect the
underlying query.
Bob

By now you could have easily setup jet security to limit write access to
your tables. It's there for a reason so why not use it?

I have used it and find it adds a layer of complexity to things. I try
to avoid if I can.

So far I found the one very simple approach, noted above.
Create a new MDB with one table with one field defined. Using the
operating system, make the mdb read only.
In the user's database, link to the real data and to the r/o database.
CReate a new query with both the real data and r/o table. Select all
fields from the real data. No need to select any data from the r/o
table or make any relation.
Save the query.
Hide the two linked table definitions.
All the user sees is the query which has the desired data but read-only.
Here is the thread where I learned how to do this:
http://groups-beta.google.com/group/...ef78d347511c73

But am still open to anything even easier than that.

Bob

[Wayne Morgan]

To unhide it to see it again, go to Tools|Options|V iew tab and check the box
next to Hidden Objects. Don't hide the table using code, there is a bug that
can cause you problems.

--
Wayne Morgan
MS Access MVP
"Bob Alston" <tu************ ****@cox.net> wrote in message
news:NKeGe.5357 7$4o.5708@fed1r ead06...

Wayne Morgan wrote:

While this won't stop them if they get access to the database window, you
could make the queries "Snapshots" . Snapshots are read only and any
subsequent object based on that query will also be read only for data
that comes from that query. Also, reports aren't a problem, there is no
editing data that the user can do in a report. The problem would come it
if you give them access to a form or query (or the table itself) that is
read/write.

GREAT.

In the interim read about a way to relate the table to a table in a
read-only db and use the resultant query.

Your's is cleaner. And I understand I can hide the linked table entry
(but not sure how to unhide it to see it again).

Bob