AW: MaxDB fetch into problem with concatenated data in oracle mode with embedded SQL statment in C/C++ programs

Elbertus Lochtenberg wrote:

> 
> Dear Reader,
> 
> Within my C/C++ program y tried to do get some concatenated data
output
> within a cursor by using the next query:
> 
> exec sql declare Cursor_Ocupaciones cursor for
>              select rpad(to_char(cod_programa),10,' ') ||
>              rpad(rtrim(tabla,' '),20) ||
>              rpad(to_char(orden),10,' ')
>              from guf_ocupaciones;
> 
> The columns "cod_programa" and "orden" are defined as number(10).
> The column "tabla" is defined as varchar2(100).
> 
> The output of the fetch is send to the host variable "query_out",
> defined as char[1000], and initialised before each fetch with nulls.
> 
> The first problem consists that after de obtained concatenated data,
the
> rest of the output buffer (query_out) is filled up to de end with
> blanks, and de last charter +1 (out of the buffer size) with the "@"
> character. I think the output buffer should contain only the obtained
> data ended with a null character.

Hope, another guy will answer.

> 
> The second problem is that if I try to do the same with dinamic SQL
> (prepare, declare, open and fetch), first the open fails (-2010),
> indicating that the size indicated in the "rtrim" function on the
column
> "tabla" should be at least de real column size. When I put the size at
> 100 (real column size), the program executions end in a core dump.

If in tabla a value is stored longer than 20 bytes, then the behaviour
is correct, no matter if the sql-statement was prepared dynamically or
not.
If the same table-content is used and all data is fetched one by one,
you will find even with non-dynamic statement that this error out of the
server will occur.
The question is, what do you want to receive? Column-content, truncated
to 20 bytes (use substr, it will be filled with blanks by the server) or
do you want to have at least 20 bytes, but usually the full
column-content? I cannot imagine what your idea is.

For the crash, always, always send us the info:
Version used
Trace back (can be found in knldiag)
Statement and table definition (as you did)

In this case the table content (or at least the row content making the
server core) should be send to the list (or, in this case, directly to
me).
To shorten the ping-pong of mails, in this case please prepare a vtrace
according to
http://sapdb.2scale.net/moin.cgi/VTrace
but with   DEFAULT SELECT    instead of DEFAULT in step 1 and 6 and
akbm  instead of akb in step 4 and send the result to ... (see above).
If I knew the trace back I could have said if this vtrace-preparation is
worth doing it or not...

BTW: a number (10) may need (in case of negative value or float-value)
more than 10 character for output.

Elke
SAP Labs Berlin

> 
> The same query tested in the sql client (websql and sqlcli) seems to
> works fine.
> 
> Best regards
> 
> Elbertus Lochtenberg
> Project Manager
> Teleserver S.A.
> Mobile: +34628270643
> 

--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe:    http://lists.mysql.com/maxdb?unsub=gcdm-maxdb@xxxxxxxxxxx