Hello Kathey, I overlooked this. I thought that roles were set and used on a by-user basis; personally I find it a little counter-productive that the role has to be chosen on every session. I am not totally sure how it goes on SQL Server or MySQL for example, but at least Oracle loads up all the privileges set to that user through roles. Then you can choose during that session whether you want to enable or disable certain roles: http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10004.htm
We might want to have a look into what's the most common behavior and stick with that one; if on the other hand we are sticking to our way on this and it differs from the other RDBMS' way then we might want indeed to make this more explicit and obvious. I think it is easy to overlook the fact that you have to SET a role on top of having been granted that role. Tiago On Thu, Apr 9, 2009 at 5:00 PM, Kathey Marsden <kmarsdende...@sbcglobal.net>wrote: > Tiago Espinha wrote: > >> 5) Tried to use TIAGO on another ij spawn and here is what I get: >> ij> select * from adm.t1; >> ERROR 42502: User 'TIAGO' does not have SELECT permission on column 'F1' >> of table 'ADM'.'T1'. >> > > I think before you do the select, you have to set the role, e.g > ij>set role readRole; > > Should we make this clearer in the documentation? > http://db.apache.org/derby/docs/dev/devguide/cdevcsecureroles.html > > Kathey >
