Re: Still problems with SQLCLI

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Tony,

Not only does the 4th parameter to SQLBindCol() have to be an buffer 
large enough to contain all columns for 50 rows... but also the 6th 
parameter to SQLBindCol() has to be an array large enough to contain the 
lengths for all columns in all 50 rows.

Right now you're doing this:

     D W_TMPINT        S                   LIKE(T_SQLINTEGER)

     C                   CALLP     SQLBindCol(W_RSQLHSTMT
     C                                :W_X
     C                                :DS_COLMETA.SQLTYPE
     C                                :W_REC_BUF_PT
     C                                :DS_COLMETA.LENGTH.INTEGER
     C                                :W_TMPINT)

The problem is that W_TMPINT is only one integer (4 bytes long). 
However, the system expects that the last parm to SQLBindCol is large 
enough to contain the lengths for every column in every row.  52 columns 
times 50 rows is 2600 integers (or 10400 bytes).  So you're corrupting 
10396 bytes of storage with every fetch.

As a quick test, I changed the above code to look like this, instead:

     D W_TMPINT        S                   LIKE(T_SQLINTEGER)
     D                                     DIM(2600)

     C                   CALLP     SQLBindCol(W_RSQLHSTMT
     C                                :W_X
     C                                :DS_COLMETA.SQLTYPE
     C                                :W_REC_BUF_PT
     C                                :DS_COLMETA.LENGTH.INTEGER
     C                                :W_TMPINT(1))

FWIW... that last field (the "length returned") in SQLBindCOl is laid 
out just like your record buffer.  In other words, the length for F1 is 
first, then the length for F2, then the length for F3, etc...  after the 
lengths for all 52 columns, the lengths for the second record are 
placed, with the length for F1, F2, F3, etc, again...

But, anyway... changing your code to use DIM(2600) and W_TMPINT(1), as 
above, fixed the storage corruption in my tests.  Obviously if the 
amount of rows and/or columsn changes, the size of that buffer must also 
change... so in your actual program, you may want to dynamically 
allocate the size of that W_TMPINT buffer.

Also, FYI, I had to compile your program with COMMIT(*NONE) instead of 
the default of COMMIT(*CHG).  Otherwise, the INSERT statement failed, 
and nothing was populated in the TST file.  (Which may be why some 
people reported no storage corruption running your code -- because no 
actual fetches were made since there was nothing in the test file).

Hope that all makes sense (because it took me a REALLY long time to 
figure out!!)


Tony.Weston@xxxxxxxxxxxxxx wrote:
> Hi,
>
> I am still having problems with my SQLCLI program.... No replies for my 
> last post.... Surely some technical guru here should know what I'm doing 
> wrong!...
>
> The program in question is here: http://totspics.com/sqlcli.txt
>
> To see the problem:
>
>     **Compile, Run in Debug with a breakpoint on the first 
> SQLFetchScroll()
>  
>     **When the program stops at the breakpoint, check the value of the 
> array w_RowStsArray . This will have 100 elements, all of value '11111' 
> (as initialised)
>  
>     **Step over the SQLFetchScroll, and check the value of array 
> w_RowStsArray again. This time, elements 95, and 96 will be corrupted.
>
>
> w_RowStsArray is not used anywhere in the program, yet is been corrupted. 
>
>
> As it stands, In the actual program, (which this is based on)  I have to 
> fetch records from the remote server 1 record at a time, which is very 
> slow, and the '.net people' in the office are begging to take the 'P'! 
> Help me save face!....Anyone!
>
> Many thanks in advance, to anyone able to offer any suggestions.
>
>
>
>
>
> Tony Weston
> Senior Analyst/Programmer - IT Systems