Re: 10046/10079 Tracing understanding - SOLVED
- From: Brian Wisniewski <brian_wisniewski@xxxxxxxxx>
- To: paul.baumgartel@xxxxxxxxx, oracle-l@xxxxxxxxxxxxx
- Date: Thu, 4 Aug 2005 10:17:27 -0700 (PDT)
When it was called from java it was definitely returing the entire 32K when the
OUT field was CHAR. When I called it from another PL/SQL pgm via sqlplus @..
it did NOT return the entire contents.
I'm not sure if this is a thin driver issue or what but I'm still researching
this. I'm going to try the OCI driver next and see if that makes a difference
or not.
That was fun to track down in a twisted sort of way.
- Brian
Paul Baumgartel <paul.baumgartel@xxxxxxxxx> wrote:
Yikes.
So Oracle will always allocate and use a 32K buffer for an output
variable defined simply as CHAR?
Thanks for the update.
On 8/4/05, Brian Wisniewski
wrote:
> I finally figured out the problem with the SQL*Net more data to client
> problem. The developer defined output variables as CHAR since he was only
> passing back a single character.
>
> Well the max size of a CHAR field in a procedure is 32K and it's fixed
> length so it was returning the value back to the calling program along with
> another 32000+ spaces to fill it out to the max possible size. And he was
> doing this with 10 fields so that's a mere 320K of spaces sent back to the
> java pgm each and every time this pkg was called! Hence the need for Oracle
> to break that down into manageable pieces to send across the network.
>
> A quick change to VARCHAR2 fixed the issue.
>
--
Paul Baumgartel
paul.baumgartel@xxxxxxxxxxxx
--
//www.freelists.org/webpage/oracle-l
---------------------------------
Yahoo! Mail
Stay connected, organized, and protected. Take the tour
Other related posts:
