View Single Post

   
  #2 (permalink)  
Old 02-27-2008, 11:48 AM
Knut Stolze
 
Posts: n/a
Default Re: SQLDA corrupted when using VARGRAPHIC type parameters

weirdwoolly@googlemail.com wrote:

> I have written a stored procedure in C++ called from a Java test
> harness to validate the graphic data types in C++ and their use.
>
> I have declared the vargraphic input parameters along the following
> lines
> in i_vargraphic100 vargraphic(100)
>
> and they are populated from String's in java.
>
> The respective host variable's are simialr to
> struct {short Length; sqldbchar Data[100] ; } i_vargraphic100 ;


I'm not sure I fully understand the situation yet. Is this host variable on
the Java side or the stored procedure side?

> The code follows the same paradigm we have used for VARCHAR which have
> worked successfuly.
>
>>From the tests run I have experienced the following problems with

> VARGRAPHIC:
>
> 1. corruption of other sqlda entries


Where do you use the SQLDA? Are you using PARAMETER STYLE DRDA in your
procedure? If so, I would suggest that you use a different style, e.g.
SQL. The style DRDA is deprecated (and I'm not sure if the GRAPHIC data
types are/were actually supported.

> When printing out the contents of the sqlda all parameters come
> through to the C++ stored procedure correctly provided I do not
> overfill the i_vargraphic100 parameter.
>
> For example if it is past a 63 character input string it comes through
> with a zero length as do the the preceeding input parameters. But 62
> comes through fine.
> If the in parameter is changed such that it is a VARGRAPHIC(40), I can
> only get 32 characters to pass through correctly. There does not
> appear to be an algorithm to how much data is lost.
>
> 2. inability to return an OUT parameter passed in as a VARGRAPHIC even
> though it is the same size, type and structure etc
>
> A SQL0450N is returned regardless.


Could you show us the code of the SP and how you access/set the SQLVAR
structures in the SQLDA?

> 3. LONG VARGRAPHIC is sqltype 465 whereas documentation suggests it is
> 473


464 is VARGRAPHIC w/o NULL
465 is VARGRAPHIC with NULL
472 is LONG VARGRAPHIC w/o NULL
472 is LONG VARGRAPHIC with NULL

You should make sure that you don't mix up LONG VARGRAPHIC and VARGRAPHIC.
I suspect that your problem may be found in that.

--
Knut Stolze
DB2 z/OS Utilities Development
IBM Germany
Reply With Quote