> I do not think it is a good idea to select from V$ tables: many users
> are not granted permission to see select from those.
OK - most V$ views need additonal privileges, but V$NLS_PARAMETERS has a
public synonym and SELECT is granted to PUBLIC - there are another 22 v$
views (out of 188) in 8i that are 'public' like this.
I can select from the view without any privileges beyond CREATE SESSION on a
fresh install of 8i:
Connected to Oracle8i Enterprise Edition Release 8.1.7.4.1
Connected as sys
SQL> create user noprivs identified by noprivs;
User created
SQL> grant create session to noprivs;
Grant succeeded
SQL> connect noprivs/[EMAIL PROTECTED]
Connected to Oracle8i Enterprise Edition Release 8.1.7.4.1
Connected as noprivs
SQL> select count(*) from v$nls_parameters;
COUNT(*)
----------
17
So does this privilege commonly get revoked?
If it's to change to use NLS_DATABASE_PARAMETERS, it needs to take into
account NLS_SESSION_PARAMETERS as well to pick up things like the session's
NLS_DATE_FORMAT. Does it need to consider NLS_INSTANCE_PARAMETERS? I don't
know what the interaction here is - which is probably why v$nls_parameters
is there, to get Oracle to work that out :-)
> $ENV{NLS_LANG} should give you the client NLS environment.
On most platforms yes, and assuming you haven't changed it since the
connect. On Windows there's the registry to worry about (which looks a bit
of a pain in a multiple-home environment).
Also you could conceivably open one $dbh with NLS_LANG as Unicode, change
NLS_LANG and open a second one in single-byte; the first one would still be
in Unicode as it's only at connect time that NLS_LANG makes a difference,
but a method based on the current value of NLS_LANG would then give the
wrong answer for the first $dbh.
--
Andy Hassall <[EMAIL PROTECTED]> / Space: disk usage analysis tool
<http://www.andyh.co.uk> / <http://www.andyhsoftware.co.uk/space>
