Subject changed from "test_dynamic Error 29 installing DBD-Oracle v 1.15
on red hat 9 Oracle 9.2"
To be honest, it is stunning how complicated they (oracle/we in IT?)
have made this. Its indicative of a moving spec, and lack of
agreement. Which is obvious when one reads the oracle documentation.
(which is pretty confusing).
On Sat, 2004-03-20 at 09:12, Andy Hassall wrote:
> > 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 stand corrected.
[snip]
> So does this privilege commonly get revoked?
Probably not.
> 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.
Ok, I'm fine with that last statement, but see my first comment above.
Given, there is no privs problem, what do we think is likely to be most
stable (i.e. not change) going forward? And what do we think is going
to "just work" in the majority of cases, where the user does nothing
special?
I am beginning to think that we need to define exactly what
ora_can_unicode means exactly. I think this is a far more complicated
problem than it appears when one just asks "can oracle do unicode".
Should not the method answer the question for both the NLS_CHARACTERSET
AND the NLS_NCHAR_CHARACTERSET? And then, as you point out, what do we
do about alter session statements.
Without a set of input arguements to indicate what question one is
asking, I wonder how useful it will be.
Does it mean the default CHAR types support unicode?, or does it mean
the NCHAR types support unicode?, if so, does it mean that THIS session
can use unicode? I suppose it could it return an array or hash
reference, that would avoid the need to define input parameters. But
given alter session and the ability of the use to change NLS_LANG and do
a new connect, I think it should not cache answers. That should
probably be up to the user, who should know what he is doing.
And since I have broached idea of returning a hash ref, perhaps there
should really be two methods:
ora_database_parameters
ora_session_paramaters
Each of which returns a hash refer of all parameters available.
Of course, there is still the problem of getting dbd-oracle to actually
work with nchar data. For me its back to that problem... (and figuring
out how to get svn to do an update... I get an error).
Lincoln
