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

[Jesse Vincent]

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
> 
> 

--