[Rt-devel] Re: Problem (and workaround) with Handle.pm in DBIx::SearchQuery used by RT

[Stephen Turner]

Hi,

I was wondering if this problem has been resolved? I encountered the same 
issue myself and ran into a correspondence between Jesse and the humble, 
helpful folks at DBD::Oracle which didn't seem to suggest a solution.

I'm unable to create new users through the web interface, I get an 
ORA-12704 on the Users insert. One piece of information that may be useful 
is that I AM able to create users using a command-line perl script that 
calls the RT API.

Steve

At Tuesday 11/30/2004 07:19 PM, Jesse Vincent wrote:

>On Tue, Nov 30, 2004 at 03:54:05PM -0800, Pei Ku wrote:
> > Hi,
> >
> > First of all, if this is wrong protocol for communication issues, my 
> apology.  I'm not very familiar with open source development 
> bug-reporting protocol.
>
>Hi Pei,
>
>         Thanks very much for the error report.   Generally,
>DBIx-SearchBuilder gets discussed on the rt-devel mailinglist, but I'll
>take good bug reports with extensive triage like yours in whatever
>format and forum I can get them ;)
>
>
> > I am trying to get RT running against an Oracle 9.2.0.4 db.  Here is a 
> summary of what my environment looks like:
> >
> > "App" server is Redhat 8, running the following:
> > 
> httpd-2.0.52/         mod_fastcgi-2.4.2/        perl-5.8.5/         rt-3.2.2/
> > oracle client is 9.2.0.4 for RH/linux
>
>And I'm betting DBD::Oracle 1.16. The error you report has popped up
>since the upgrade to 1.16. Backing down to 1.15 makes it go away again.
>That doesn't mean it's not our bug, just that it wasn't tickled before
>this release.
>
>
> > ORA-12704 seems to surface when CLOB/NCLOB columns are used (based on 
> information from Oracle Metalink support).   The error description seems 
> to indicate this is something that can be fixed with setting NLS_LANG in 
> the client environment; I tried to tweak it to no avail.  In any case, RT 
> seems to hardcode the value to ".UTF8" in the code anyway.
>
>Do you have a sense of what it _should_ be? Everything we've read
>implies that .UTF8 should be acceptable.
>
>
> > Being an Oracle DBA and an occassional perl hacker, I took the 
> challenge to see if I can see what's going on.  After staring the code in 
> Handle.pm ( DBIx::SearchBuilder v1.15) for a while, I uncommented one 
> line and then I was able the get rid of the problem.  The line I 
> uncommented out is line #464
>
>By uncommented out, you really mean "commented out", right?
>
>
>
> >     460         if ( ref( $bind_values[$bind_idx] ) eq "HASH" ) {
> >     461             my $bhash = $bind_values[$bind_idx];
> >     462             $bind_values[$bind_idx] = $bhash->{'value'};
> >     463             delete $bhash->{'value'};
> >     464             #     $sth->bind_param( $bind_idx + 1, undef, $bhash );
> >     465         }
> >
> >     ...
> >
> >     475         eval { $executed = $sth->execute(@bind_values) };
> >
> >
> > I am not a Perl guru, but it looks me line #464 is unnecessary: when 
> $sth->execute is called at line 475, @bind_values is passed as the 
> input.  My understanding is that one should either use $sth->bind_param 
> to set up all the bind values before calling execute(), or just pass 
> @bind_values to $sth->execute(), but not both.  It may be ok to do both 
> (what would take precendence, then?  values set up by bind_param(), or 
> values passed to execute()?), but in some weird cases (such as the 
> presence of CLOB columns in a table), things break.
> >
> > line #464 seems to be binding 'undef' to @bind_values only for those 
> elements that were a HASH/ref.   So line #464 is not really performing 
> binding for all the bind variables; it's only setting those that were a 
> HASH to undef.  I guess I don't understand the rationale behind that.
>
>I'm going to have to dig a bit deeper. I can't remember whether that
>code was added to deal with oracle param binding or something else.
>
>Does a "make regression" pass with your change?
>
>
> > At any rate, now I am able to create new users after commenting out 
> that line.  I don't know if I created new problems by making this change.
> >
> > thanks!
> >
> >
> >
> > Pei L. Ku
> > Manager, Application and Database Services
> > ATC
> > pku at autotradecenter.com
> > office: 650 532 6318
> >
> >
>
>--
>_______________________________________________
>Rt-devel mailing list
>Rt-devel at lists.bestpractical.com
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Stephen Turner
Senior Programmer/Analyst - Client Support Services
Information Services and Technology (IS&T)

sturner at mit.edu