unixODBC problem in HP-UX IA64

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

unixODBC problem in HP-UX IA64

手嶋 和徹
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
HPUX aCC
・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

best regards.

Thank you.

_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: unixODBC problem in HP-UX IA64

Nick Gorham-2
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
> HPUX aCC
> ・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
Hi,

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.

--
Nick
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: unixODBC problem in HP-UX IA64

手嶋 和徹
(2013/11/14 19:12), Nick Gorham wrote:

> 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
>> HPUX aCC
>> ・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
> Hi,
>
> 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.
>

Hi.

Thank you for Reply,Nick san.

I am appologize for omit SQLBindCol.

SQLBindCol(hstmt, 1, SQL_CHAR, (SQLPOINTER) RowData[0].xxx,10, &len);
SQLBindCol(hstmt, 2, SQL_CHAR, (SQLPOINTER) RowData[0].yyy,15, &len);

and Oracle table define is
samle_table
(xxx char(10),
 yyy char(15))

> And check what the actual number of rows is
> being set to. Does it match the actual memory allocated.

rows set integer number 20.

Yes. i think rowsize = 25.exactly.
※27 is mistake.

but,actually run is rowsize = 51.
It may caused multiLanguage Oracle's (Char)Bytes Problem...?

I try to check Char length.

If you know a simular case,please tell me.

I'm afraid I might no be good english,so I look forward to your king help.
Thank you for your reply.

kazu.

_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support
Reply | Threaded
Open this post in threaded view
|

Re: unixODBC problem in HP-UX IA64

Nick Gorham-2
On 14/11/13 12:13, 手嶋 和徹 wrote:

> (2013/11/14 19:12), Nick Gorham wrote:
>> On 14/11/13 10:01, 手嶋 和徹 wrote:
>>
> Hi.
>
> Thank you for Reply,Nick san.
>
> I am appologize for omit SQLBindCol.
>
> SQLBindCol(hstmt, 1, SQL_CHAR, (SQLPOINTER) RowData[0].xxx,10, &len);
> SQLBindCol(hstmt, 2, SQL_CHAR, (SQLPOINTER) RowData[0].yyy,15, &len);
>
> and Oracle table define is
> samle_table
> (xxx char(10),
>  yyy char(15))

Hmm,

If you are using row-wise binding, I would expect

#define ROWCOUNT 100

struct test{
        SQLCHAR  xxx[10],
        SQLLEN len1;
        SQLCHAR  yyy[15]
        SQLLEN len2;
};

struct test RowData[ ROWCOUNT ];

I would not use class, I would distrust there is no c++ magic being added. Though the fact that the elements are referred to by the address of the first element should mean it doesnt matter.

Then

SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_BIND_TYPE, (SQLPOINTER) sizeof( struct test ), NULL);
SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER) ROWCOUNT, NULL);

SQLBindCol(hstmt, 1, SQL_CHAR, (SQLPOINTER) RowData[0].xxx,10, &RowData[0].len1);
SQLBindCol(hstmt, 2, SQL_CHAR, (SQLPOINTER) RowData[0].yyy,15, &RowData[0].len2);

--
Nick
_______________________________________________
unixODBC-support mailing list
[hidden email]
http://mailman.unixodbc.org/mailman/listinfo/unixodbc-support