Hello Andreas,
> i recently started to dive into the SQLDBC lib to check it out to get
> the pro's and con's of using it before killing some thousand lines of
> CPC code and replace it (finally!) with a fine C++ lib.
>
> so far i've wrote some simple testcases to get a feeling of
> SQLDBC wich
> almost worked out fine.
>
> despite of the good documentation (thx Doxygen) some
> clarifications are
> needed.
> to begin with i assume that the SQLDBC lib is now an
> *official* part of
> the
> MaxDB API wich is constantly supported, fixed and improved
> like the other
> API's and that we can use in production code for years to come.
> is this correct ?
SQLDBC is/will be constantly supported, as it is/will the base of
other interfaces, such as the Perl DBM implementation, the PHP
module (not yet there), and an upcoming version of the ODBC driver.
> what are the real differences between a HOSTTYPE_BINARY and a
> HOSTTYPE_GUID
> --------------------------------------------------------------
> -------------
> i assume that a BINARY is just that: some arbitrary bytes,
> any values and
> any length allowed, whereas a GUID is *exactly* 16 bytes
Right. There is simply such a type in ODBC.
> 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.
> the next post to come is about fetching into arrays using
> ResultSet and
> RowSet, how to cope with the arrays, when to call what,
> bindColumn() for
> arrays etc.
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.
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];
s->getResultSet()->bindColumn(1, SQLDBC_HOSTTYPE_ASCII, a_values, a_ind, 20, true);
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).
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]
