SQLDBC handling needs some clarifications
=========================================
hello list,
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 ?
for the remaining text the following config is in effect:
OS : Win 2000 Prof. SP 4
Kernel: 7.5.0 Build 014-123-073-298
everything clean installed from:
maxdb-all-win-32bit-i386-7_5_00_14.zip from 2004-June-03 17:50
maxdb-sqldbc-win-32bit-i386-7_5_00_14.tgz from 2004-June-03 17:13
(thats the download dates, so i got the latest files of this distro i
think)
the SQLDBC info-calls return
SQLDBC Header Version: SQLDBC.H 7.5.0 BUILD 014-123-073-156
Kernel Version : 70500
AutoCommit : OFF
Transact. Isolation : 1
Date Time Format : ISO (ODBC, JDBC)
Unicode Database : NO
working with default (unchanged) connect properties, so i think SQL-Mode
INTERNAL is in effect.
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
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)
BUT NO CONVERSION of any kind is ever applied to GUID
is this correct ?
HOSTTYPE_GUID and corresponding table definition
------------------------------------------------
i assume that the corresponding column definition for a GUID of a table
should be CHAR BYTE as in the following example:
CREATE TABLE tabname (
colname CHAR(16) BYTE,
...
)
is this correct ?
for example the following statements work fine for me (err handling
omitted) but is there any hidden pitfall i could get into ?
CREATE TABLE tabname (
id CHAR(16) BYTE NOT NULL,
...
...
PRIMARY KEY (id)
)
// insert //////////
stmt = m_pConn->createPreparedStatement();
rc = stmt->prepare("INSERT tabname (id, ...) VALUES (?, ...)");
SQLDBC_Length li;
li = 16; // set to 16 bytes for id
rc = stmt->bindParameter(1, SQLDBC_HOSTTYPE_GUID , &id, &li, 16);
...
rc = stmt->execute();
rc = m_pConn->commit();
// select //////////
rc = stmt->prepare("SELECT * FROM tabname WHERE id = ?");
// hostvar style
struct {
char id[17];
...
} hTheUserPM;
memset(&hTheUserPM, 0, sizeof(hTheUserPM));
...
SQLDBC_Length li;
li = 16; // set to 16 bytes for id
rc = stmt->bindParameter(1, SQLDBC_HOSTTYPE_GUID , &hTheUserPM.id, &li,
16);
...
rc = stmt->execute();
SQLDBC::SQLDBC_ResultSet * rs = 0;
rs = stmt->getResultSet();
rc = rs->next();
rc = rs->getObject(1, SQLDBC_HOSTTYPE_GUID, &hTheUserPM.id, &li,
sizeof(hTheUserPM.id));
...
rs->close();
please don't mind that i fetch the GUID into a char[], i have special
helper functions that convert the binary representation of a GUID into a
human readable std::string back and forth at wish .. we all know it's only
some bytes ..
i hope that the length and detailism of this post is not to offending.
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.
looking forward to your answers
thanks in advance
andreas bohn
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
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]
