> > it seems that in some cases a conversion is done with BINARY
> > if some 0x00
> > bytes are embedded, i.e. with the bytes 0xCD 0xCD 0x00 0x00 0xFF 0xFF
> > inserted in a table, only 0xCD 0xCD is inserted followed by 0x20's (as
> > SQLStu shows of)
>
> Have you tried to bind the data non-null-terminated? (I.e. set the
> last parameter of bindParameter to false.) Anyway, such a
> null-terminator
> check for binary data is very probably not a feature ... thanks for
> reporting.
no, i've omitted the last parameter, so it defaulted to TRUE
> Declare a C array of the data to fetch, bind the pointer, and set the
> rowset
> size to the size of the array, then navigate to the place in the result
> set
> which you want, and call the fetch() method to convert the data into
> your
> arrays. You may want to bind an array of indicator values, too.
i think ist must read:
You MUST ALSO bind an array of indicator values, too.
otherwise fetch() will overwrite FETCHSIZE bytes starting from the
indicator-value address with it's return-indicator-value for the given
rows, garbling our memory...oops
> E.g. having a table
> CREATE TABLE TEST(A CHAR(20), B INTEGER)
>
> you would maybe do something like
>
> SQLDBC_Statement *s = connection->createStatement();
> s->execute("SELECT * FROM TEST");
>
> char a_values[21][200];
> SQLDBC_Length a_ind[200];
> int b_values[200];
> SQLDBC_Length b_ind[200];
OOPS, should read:
char a_values [200][21];
otherwise SQLDBC_DATA_TRUNC is returned by fetch() and mixed garbage is in
our hostvar
> s->getResultSet()->bindColumn(1, SQLDBC_HOSTTYPE_ASCII, a_values,
> a_ind, 20, true);
OOPS, must say:
s->getResultSet()->bindColumn(1, SQLDBC_HOSTTYPE_ASCII, a_values, a_ind,
21, true);
we MUST give the REAL no of bytes (21) of the host-char-field to the
Size parameter, NOT the char count from the tabledef, otherwise we're
sitting on an off-by-one error
> s->getResultSet()->bindColumn(1, SQLDBC_HOSTTYPE_INT4, b_values,
> b_ind, sizeof(int), false);
> s->getResultSet()->setRowsetSize(200);
>
> s->getResultSet()->first();
> s->getResultSet()->fetch();
>
> afterwards you can call getRowsAffected on the rowsset
> (s->getResultSet()->getRowSet()), which reports
> how many rows actually were fetched (should be 200, except for the last
> block).
thanks for the hint to getRowsAffected(); this works.
i've tried resultset's getResultCount(), but it returned -1 every time.
only after fetching the whole table several times with the new born
array-fetch, getResultCount managed it to return the size of the result
it is also neccessary to call fetch() for every step with a block-cursor,
i.e.
first();
fetch(); // we have our first FETCHSIZE rows now
while(still something to fetch) {
next();
fetch(); // NOW we have our next FETCHSIZE rows
}
this is not written in the doc clearly, so you might consider to clarify
this for using block cursors
regards
Andreas Bohn
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
