By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,696 Members | 1,424 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,696 IT Pros & Developers. It's quick & easy.

Make Table Query in secured DB

P: n/a
I have a secured database that contains a Read-Only group. This group
has permissions to view reports, but cannot add, edit, or delete any
DB objects. One of the reports the group needs access to is generated
with a Make-Table Query. Since the Make-Table Query deletes the
previous table it created everytime it's ran, this poses a problem
since the Read-Only group doesn't have the permission to delete
objects. This causes the report request to be halted. I can actually
choose to unsecure the table, but when it's deleted and recreated
after the query is ran, it's recreated as a secured object. So I'm in
a security loop here.

Any suggestions would be appreciated...
Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
ha*********@hotmail.com (Oreo Bomb) wrote in
news:11**************************@posting.google.c om:
I have a secured database that contains a Read-Only group. This group
has permissions to view reports, but cannot add, edit, or delete any
DB objects. One of the reports the group needs access to is generated
with a Make-Table Query. Since the Make-Table Query deletes the
previous table it created everytime it's ran, this poses a problem
since the Read-Only group doesn't have the permission to delete
objects. This causes the report request to be halted. I can actually
choose to unsecure the table, but when it's deleted and recreated
after the query is ran, it's recreated as a secured object. So I'm in
a security loop here.

Any suggestions would be appreciated...


Base the report on a query.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #2

P: n/a
Lyle Fairfield <Mi************@Invalid.Com> wrote in message news:<Xn*******************@130.133.1.17>...
ha*********@hotmail.com (Oreo Bomb) wrote in
news:11**************************@posting.google.c om:
I have a secured database that contains a Read-Only group. This group
has permissions to view reports, but cannot add, edit, or delete any
DB objects. One of the reports the group needs access to is generated
with a Make-Table Query. Since the Make-Table Query deletes the
previous table it created everytime it's ran, this poses a problem
since the Read-Only group doesn't have the permission to delete
objects. This causes the report request to be halted. I can actually
choose to unsecure the table, but when it's deleted and recreated
after the query is ran, it's recreated as a secured object. So I'm in
a security loop here.

Any suggestions would be appreciated...


Base the report on a query.

Well, in my situation I have about five seperate reports that get
rolled into one consolidated report using a certain date range of
data. The reason I use a Make-Table Query as the source of my reports
is that I only have to enter in a data prompt once to strip out the
data I need, rather than five seperate times when I run the
consolidated report. If I do redesign the reports straight from a
query, how can I eliminate Access prompting me multiple times for the
same date range?
Nov 12 '05 #3

P: n/a
ha*********@hotmail.com (Oreo Bomb) wrote in
news:11**************************@posting.google.c om:
Lyle Fairfield <Mi************@Invalid.Com> wrote in message
news:<Xn*******************@130.133.1.17>...
ha*********@hotmail.com (Oreo Bomb) wrote in
news:11**************************@posting.google.c om:
> I have a secured database that contains a Read-Only group. This
> group has permissions to view reports, but cannot add, edit, or
> delete any DB objects. One of the reports the group needs access to
> is generated with a Make-Table Query. Since the Make-Table Query
> deletes the previous table it created everytime it's ran, this poses
> a problem since the Read-Only group doesn't have the permission to
> delete objects. This causes the report request to be halted. I can
> actually choose to unsecure the table, but when it's deleted and
> recreated after the query is ran, it's recreated as a secured object.
> So I'm in a security loop here.
>
> Any suggestions would be appreciated...


Base the report on a query.

Well, in my situation I have about five seperate reports that get
rolled into one consolidated report using a certain date range of
data. The reason I use a Make-Table Query as the source of my reports
is that I only have to enter in a data prompt once to strip out the
data I need, rather than five seperate times when I run the
consolidated report. If I do redesign the reports straight from a
query, how can I eliminate Access prompting me multiple times for the
same date range?


I'm !!!strictly guessing!!! about what you want to do, and thinking that you
cannot do it with a query without being prompted for the parameters each time
you open a report,unless you learn a little VBA and change the QueryDef's SQl
before running the reports eg:

Set qdf = DBEngine(0)(0).QueryDefs(qryChargesName)
With qdf
.SQL = "SELECT * FROM tblCharges WHERE Sent = No And Account = Chr
(34) & strAccountNumber & Chr(34)

or unless you set the SQL to reference some form control value or public
function.

It might be worth your while to learn a little VBA, (I apologize if I'm wrong
and you already know this) as it would enhance your Access capability
enormously.

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)
Nov 12 '05 #4

P: n/a
Lyle Fairfield <Mi************@Invalid.Com> wrote in message news:<Xn*******************@130.133.1.17>...
ha*********@hotmail.com (Oreo Bomb) wrote in
news:11**************************@posting.google.c om:
Lyle Fairfield <Mi************@Invalid.Com> wrote in message
news:<Xn*******************@130.133.1.17>...
ha*********@hotmail.com (Oreo Bomb) wrote in
news:11**************************@posting.google.c om:

> I have a secured database that contains a Read-Only group. This
> group has permissions to view reports, but cannot add, edit, or
> delete any DB objects. One of the reports the group needs access to
> is generated with a Make-Table Query. Since the Make-Table Query
> deletes the previous table it created everytime it's ran, this poses
> a problem since the Read-Only group doesn't have the permission to
> delete objects. This causes the report request to be halted. I can
> actually choose to unsecure the table, but when it's deleted and
> recreated after the query is ran, it's recreated as a secured object.
> So I'm in a security loop here.
>
> Any suggestions would be appreciated...

Base the report on a query.

Well, in my situation I have about five seperate reports that get
rolled into one consolidated report using a certain date range of
data. The reason I use a Make-Table Query as the source of my reports
is that I only have to enter in a data prompt once to strip out the
data I need, rather than five seperate times when I run the
consolidated report. If I do redesign the reports straight from a
query, how can I eliminate Access prompting me multiple times for the
same date range?


I'm !!!strictly guessing!!! about what you want to do, and thinking that you
cannot do it with a query without being prompted for the parameters each time
you open a report,unless you learn a little VBA and change the QueryDef's SQl
before running the reports eg:

Set qdf = DBEngine(0)(0).QueryDefs(qryChargesName)
With qdf
.SQL = "SELECT * FROM tblCharges WHERE Sent = No And Account = Chr
(34) & strAccountNumber & Chr(34)

or unless you set the SQL to reference some form control value or public
function.

It might be worth your while to learn a little VBA, (I apologize if I'm wrong
and you already know this) as it would enhance your Access capability
enormously.


I'll give it a shot, and I do appreciate the coding, even if it's a
guess! I really do need to learn VBA for Access because I keep
hitting these annoying little walls that the built-in tools can't
handle. I'm pretty familiar with VBA for Excel, but it's a bit
different for Access.

Thanks again!
Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.