RE: [SUSPECTED SPAM] Use of adopted profiles

These are two separate issues. It's not so much a "group profile vs
authorization list" issue, well, maybe a little.

It's more of a "application only access" issue. Basically the application
should have access to the data, not the users. The users should really
not have update access to the data. Programs will do the updating. Do
the users need to be able to do on the fly requests to all your data like
"update paydata set payrate = payrate*1.5"? If they do then go ahead and
secure the data with a group profile and put the users in there and forget
about adopted authority. But I really doubt they do. Instead restrict
updates to those performed by adopted authority programs and restricted
reading the data directly to those few users who need to do on the fly
queries.

One benefit to using authorization lists instead of multiple groups is
that it's just easier to maintain authorization lists on the fly.
Let's say you currently have a single user (not a group) called PGMADOPT
and one group called QRYMAVEN.
*public *exclude
PGMADOPT *all
QRYMAVEN *use
Now you find you need to add an analyst to be able to update it directly
to fix flaws until they get addressed. You will have to get an exclusive
lock on the objects to add this analyst. With an authorization list you
can update their level of access on the fly.

Rob Berendt