[Zope-DB] Problem with DCOracle2 stored procedure calls

[Matthew T. Kromer]

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

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/