Hello Andreas,
> > 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
>
That's at least explaining it ... however you now have a workaround.
>
> > 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.
If there is a NULL pointer bound, it will be detected and means that
you simply don't want the indicators, because you are so self-confident
... in case you put anything other, it MUST be an array of appropriate
length.
...
> OOPS, should read:
> char a_values [200][21];
>
Yes, of course :-)
> 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);
Yes, I did just type it from memory ... so don't nail me for 110%
exactness here ... :-)
>
> 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.
That is the result count the database tells us, except if we know
some better value ...
> only after fetching the whole table several times with the new born
> array-fetch, getResultCount managed it to return the size of
> the result
... which is the case when the complete result has been fetched.
>
> 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
Yes, it is, and yes, we should possibly clarify that.
Not fetchsize, 'row array size'. There is a 'fetch size' parameter too,
which tells how many rows should be tried to get at once from the database.
The row array is always filled up, except in the last call, of course.
Regards
Alexander Schr�der
SAP DB, SAP Labs Berlin
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
