Re: Strange problem ? - Mailing list pgsql-odbc

From Lothar Behrens
Subject Re: Strange problem ?
Date
Msg-id c52b0b85411b4e61e455ee31f787c5e6@lollisoft.de
Whole thread Raw
In response to Re: Strange problem ?  (Ludek Finstrle <luf@pzkagis.cz>)
Responses Re: Strange problem ?  (Ludek Finstrle <luf@pzkagis.cz>)
List pgsql-odbc

Am 24.01.2006 um 13:11 schrieb Ludek Finstrle:


<excerpt><excerpt>I have two computers, each with SuSE 9.1 and
unixODBC with psqlodbc

07.03.0200.

</excerpt>

Are you sure that both psqlODBC are same?

</excerpt>

Yes, at most. I copied the driver from my work notebook to the test
box - both are SuSE 9.1.

I have compared the unixODBC version - 2.2.8. Had some trouble with
the psqlpdbcS.so file

not on my test box, I also copied that file (for ODBCConfig) to my
testbox.


As of that I have a test application (mentioned in my other posts
here), which works while doing

the same test, my class wrapper may do some things different. I have
done a strace on the system

calls for both and only find relevant differences in that my
application (wrapper) seems to hang.


Today I will gather some API logs as of activating them in the driver.
But not in the next hour.

I hope, which that I can get more information about the differences -
better than comparing code

or the strace diffs.


Is there a switch to activate the server side logging.


Here are the differences in short:


Dave's plain test:


<fixed>    retcode = SQLSetStmtOption(hstmt_select, SQL_ATTR_CONCURRENCY,
SQL_CONCUR_ROWVER);

    <color><param>7676,0F0F,5050</param>if</color> (retcode !=
SQL_SUCCESS)
dbError(<color><param>8989,1313,1515</param>"SQLSetStmtOption()"</color>,
hstmt_select);



    retcode = SQLSetStmtOption(hstmt_select, SQL_CURSOR_TYPE,
SQL_CURSOR_KEYSET_DRIVEN);

    <color><param>7676,0F0F,5050</param>if</color> (retcode !=
SQL_SUCCESS)
dbError(<color><param>8989,1313,1515</param>"SQLSetStmtOption()"</color>,
hstmt_select);



    UCHAR buf6[] = <color><param>8989,1313,1515</param>"drop table
regressiontest"</color>;



    retcode = SQLExecDirect(hstmt, buf6,
<color><param>7676,0F0F,5050</param>sizeof</color>(buf6));

    <color><param>7676,0F0F,5050</param>if</color> (retcode !=
SQL_SUCCESS)
dbError(<color><param>8989,1313,1515</param>"SQLExecDirect()"</color>,
hstmt);

</fixed>

My wrappers code (AFTER calling SQLExecDirect(...)):


<fixed>    <color><param>7676,0F0F,5050</param>const</color>
<color><param>7676,0F0F,5050</param>int</color> ArraySize =
<color><param>0000,0000,FFFF</param>1</color>;

    SQLUSMALLINT RowStatusArray[ArraySize];


    <color><param>2323,6E6E,2525</param>// Set the array size to one.</color>

    SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER)
ArraySize, <color><param>0000,0000,FFFF</param>0</color>);



    <color><param>2323,6E6E,2525</param>// Why this construct ??</color>

    SQLINTEGER csrType = SQL_CURSOR_KEYSET_DRIVEN;



    SQLSetStmtAttr(hstmt, SQL_ATTR_CURSOR_TYPE, (SQLPOINTER) csrType,
<color><param>0000,0000,FFFF</param>0</color>);

    SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_BIND_TYPE, SQL_BIND_BY_COLUMN,
<color><param>0000,0000,FFFF</param>0</color>);

    SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_STATUS_PTR, RowStatusArray,
<color><param>0000,0000,FFFF</param>0</color>);

</fixed>

Is there a problem, when I set the cursor type too last ?


<excerpt>

<excerpt>After a lot of research, I found this message may be a cause:


Test system (my program): Set SQL_CURSOR_TYPE as drivers.lie. (Program

hang)

</excerpt>

Don't you try dynamic cursor? I don't know the code very well but you

could find it in the code.

</excerpt>

Dave's sample works with KEYSET_DRIVEN cursors.


<excerpt>

<excerpt>Any hints ?

</excerpt>

You could try 07_03_ENHANCED which Dave announced few days ago.


</excerpt>

Will try that later. I wonder about that I get such problems. This is
because I think, I have

the same drivers and so on.


<excerpt>Regards,


Luf

</excerpt>

Regards, Lothar


<excerpt>

---------------------------(end of
broadcast)---------------------------

TIP 2: Don't 'kill -9' the postmaster



</excerpt>--

Lothar Behrens    |    Rapid Prototyping ...

Rosmarinstr 3        |

40235 Düsseldorf      |    www.lollisoft.de




Am 24.01.2006 um 13:11 schrieb Ludek Finstrle:

>> I have two computers, each with SuSE 9.1 and unixODBC with psqlodbc
>> 07.03.0200.
>
> Are you sure that both psqlODBC are same?

Yes, at most. I copied the driver from my work notebook to the test box
- both are SuSE 9.1.
I have compared the unixODBC version - 2.2.8. Had some trouble with the
psqlpdbcS.so file
not on my test box, I also copied that file (for ODBCConfig) to my
testbox.

As of that I have a test application (mentioned in my other posts
here), which works while doing
the same test, my class wrapper may do some things different. I have
done a strace on the system
calls for both and only find relevant differences in that my
application (wrapper) seems to hang.

Today I will gather some API logs as of activating them in the driver.
But not in the next hour.
I hope, which that I can get more information about the differences -
better than comparing code
or the strace diffs.

Is there a switch to activate the server side logging.

Here are the differences in short:

Dave's plain test:

    retcode = SQLSetStmtOption(hstmt_select, SQL_ATTR_CONCURRENCY,
SQL_CONCUR_ROWVER);
    if (retcode != SQL_SUCCESS) dbError("SQLSetStmtOption()",
hstmt_select);

    retcode = SQLSetStmtOption(hstmt_select, SQL_CURSOR_TYPE,
SQL_CURSOR_KEYSET_DRIVEN);
    if (retcode != SQL_SUCCESS) dbError("SQLSetStmtOption()",
hstmt_select);

    UCHAR buf6[] = "drop table regressiontest";

    retcode = SQLExecDirect(hstmt, buf6, sizeof(buf6));
    if (retcode != SQL_SUCCESS) dbError("SQLExecDirect()", hstmt);

My wrappers code (AFTER calling SQLExecDirect(...)):

    const int ArraySize = 1;
    SQLUSMALLINT RowStatusArray[ArraySize];

    // Set the array size to one.
    SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER) ArraySize,
0);

    // Why this construct ??
    SQLINTEGER csrType = SQL_CURSOR_KEYSET_DRIVEN;

    SQLSetStmtAttr(hstmt, SQL_ATTR_CURSOR_TYPE, (SQLPOINTER) csrType, 0);
    SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_BIND_TYPE, SQL_BIND_BY_COLUMN, 0);
    SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_STATUS_PTR, RowStatusArray, 0);

Is there a problem, when I set the cursor type too last ?

>
>> After a lot of research, I found this message may be a cause:
>>
>> Test system (my program): Set SQL_CURSOR_TYPE as drivers.lie. (Program
>> hang)
>
> Don't you try dynamic cursor? I don't know the code very well but you
> could find it in the code.

Dave's sample works with KEYSET_DRIVEN cursors.

>
>> Any hints ?
>
> You could try 07_03_ENHANCED which Dave announced few days ago.
>

Will try that later. I wonder about that I get such problems. This is
because I think, I have
the same drivers and so on.

> Regards,
>
> Luf

Regards, Lothar

>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>
>
--
Lothar Behrens    |    Rapid Prototyping ...
Rosmarinstr 3        |
40235 Düsseldorf      |    www.lollisoft.de



pgsql-odbc by date:

Previous
From: Ludek Finstrle
Date:
Subject: Re: Better version of ODBC to use with each version of Postgres
Next
From: Ludek Finstrle
Date:
Subject: Re: Problem with Blobs on XP Professional