[Zope-DB] Problem with DCOracle2 stored procedure calls

[Christian Long]

Dear Matt,

It looks like it works - Hooray!  I've got the new tracelogs if you're
interested, otherwise I'll just soldier on here.

Thank you, thank you for your help and for this fix.

Christian





Matt Kromer wrote


>
> Well nuts.
>
> Actually, what the result calls "VARCHAR2" is really SQLT_CHR, not
> SQLT_STR.  Those are all external data type representations.
>
> Now I have to look at the huge trace logs you sent.
>
>
> [... time passes ...]
>
> The good news is that I see where the conflict is coming from.  I'm
> still thinking about how to fix it.  The problem is that even though the
> binding array was created as type 1, when you wrote into it it wrote
> type 5 for the first cell.  When Oracle updated the value, this
> disagreed with the defined type of type 1.   Type 1 (SQLT_CHR) does not
> use a trailing NULL, type 5 (SQLT_STR) does.
>
> [... time passes ...]
>
> I'm going to make the code that detects the datatype conflict update the
> cell's type on write from Oracle, since this is the correct behavior.
> Also, when the BindingArray is set up and written to initially, if
> you're trying to write a string into a VARCHAR it will change the types
> and shorten the length by 1.
>
> Try doing a CVS update (I have checked in the patch) and let me know how
> it goes.
>
>
> --
> Matt Kromer
> Zope Corporation  http://www.zope.com/
>
>
> Christian Long wrote:
>
> >Hi Matt, list
> >
> >Thanks for your reply.  I followed your suggestions,
> unfortunately I'm still
> >having the same problem.  Looks like the problem only comes for IN OUT
> >parameters where I'm passing something in.  It also looks like DCOracle2
> >does correctly identify the parameters as VARCHAR2. Old and new
> versions of
> >DCOracle2 produced identical results for
> >print cursor.procedures.prociapi.adjust_inventory.__doc__
> >and
> >print cursor.procedures.prociapi.icbm_move.__doc__
> >(see results below).
> >
> >Any other diagnostic info I can get for you?
> >
> >Any thoughts on a workaround for now?  Can I write the call with a
> >BindingArray instead of using callproc?  I'm not at all sure how
> to do that.
> >
> >
> >Thanks
> >
> >Christian
> >
> >