[unixODBC-support] unixODBC problem in HP-UX IA64

Nick Gorham nick at lurcher.org
Thu Nov 14 10:12:31 GMT 2013

On 14/11/13 10:01, 手嶋 和徹 wrote:
> Hi
> My name is kazu teshima.
> I'm now  tring to convert IBM/CLI(64bit) C++ Program to HPUX/unixODBC(64bit) C++ with odbcUNIX Driver(2.3.0).
> ※try to connect to Oracle 11g
> but,some case when Reply have more 2 records,then unixODBC Fetch stoped.
> Promgram is simple.
> Class Define:
> class test{
> SQLCHAR  xxx[10],
> SQLCHAR  yyy[15]
> }
> Program
> ・PrepareSel
>     rowsize = (SQLLEN)sizeof(class test)
>     SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_BIND_TYPE, (SQLPOINTER) rowsize, NULL);
>     SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER) &rows, NULL);
>     SQLPrepare(hstmt, (SQLCHAR*) getSqlstmt().c_str(), SQL_NTS);
> ・open
>   SQLExecute(hstmt);
> ・fetch
>   SQLFetch(hstmt);  ⇒Stopped.
> when this case ,I thought rowsize = 27(length of [xxx]+"\0"+length[+yyy]+"\0") is correct,but this rowsize
> causes Fetch stopped. and the other rowsize ( For example rowsize = 51) is passed.
> I'd like to know the following.
> 1. why rowsize = 51 is correct?what's the logic of calculate rowsize?
> 2. Please tell me the url in this case source.
>   SQLSetStmtAttr/SQLExecute/SQLFetch

Hard to say as I suspect there is stuff you are missing out (like
SQLBindCol for example). rowsize in your case will be set to 25. two
arrays, 10 and 15 characters long, C doesn't add a magic space for the
null. rows in the ROW_ARRAY_SIZE looks odd being a pointer, it should be
a integer number of rows to return in each fetch. I suspect there is
some logic faults in the size of test.xxx and test.yyy that you are
passing in the (not show) SQLBindCol. The length of the field will have
to include the space for the NULL, so you should be sending in a length
of 10 and 15, not 11 and 16. And check what the actual number of rows is
being set to. Does it match the actual memory allocated.

But the above doesnt look this its a unixODBC problem, it most likely
will be a problem with the code or the driver. I find it best to always
assume your own code is the cause of most problems.


More information about the unixODBC-support mailing list