Strange problem ?

Strange problem ?

am 23.01.2006 23:47:13 von Lothar Behrens

Hi,

I have two computers, each with SuSE 9.1 and unixODBC with psqlodbc
07.03.0200.
On my work system all goes well, but on my test system I get problems -
or a hang.

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)
Test sytem (test app from Dave): Set SQL_CURSOR_TYPE to
SQL_CURSOR_KEYSET_DRIVEN.

In short, this is what I found today.

What is this meaning ?

Any hints ?

Thanks, Lothar


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Re: Strange problem ?

am 24.01.2006 13:11:03 von 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?

> 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.

> Any hints ?

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

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: Strange problem ?

am 24.01.2006 14:25:13 von Lothar Behrens

--Apple-Mail-1-888123249
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=ISO-8859-1;
format=flowed


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=20=

- both are SuSE 9.1.
I have compared the unixODBC version - 2.2.8. Had some trouble with the=20=

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

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

Today I will gather some API logs as of activating them in the driver.=20=

But not in the next hour.
I hope, which that I can get more information about the differences -=20
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 =3D SQLSetStmtOption(hstmt_select, SQL_ATTR_CONCURRENCY,=20=

SQL_CONCUR_ROWVER);
if (retcode !=3D SQL_SUCCESS) dbError("SQLSetStmtOption()",=20
hstmt_select);
=09
retcode =3D SQLSetStmtOption(hstmt_select, SQL_CURSOR_TYPE,=20
SQL_CURSOR_KEYSET_DRIVEN);
if (retcode !=3D SQL_SUCCESS) dbError("SQLSetStmtOption()",=20
hstmt_select);
=09
UCHAR buf6[] =3D "drop table regressiontest";
=09
retcode =3D SQLExecDirect(hstmt, buf6, sizeof(buf6));
if (retcode !=3D SQL_SUCCESS) dbError("SQLExecDirect()", hstmt);

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

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

// Set the array size to one.
SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER) =
ArraySize,=20
0);
=09
// Why this construct ??
SQLINTEGER csrType =3D SQL_CURSOR_KEYSET_DRIVEN;
=09
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=20
because I think, I have
the same drivers and so on.

> Regards,
>
> Luf

Regards, Lothar

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



--Apple-Mail-1-888123249
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=ISO-8859-1



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?=20



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 =3D SQLSetStmtOption(hstmt_select, SQL_ATTR_CONCURRENCY,
SQL_CONCUR_ROWVER);

7676,0F0F,5050if (retcode !=3D
SQL_SUCCESS)
=
dbError(8989,1313,1515"SQLSetStmtOption()",
hstmt_select);

=09

retcode =3D SQLSetStmtOption(hstmt_select, SQL_CURSOR_TYPE,
SQL_CURSOR_KEYSET_DRIVEN);

7676,0F0F,5050if (retcode !=3D
SQL_SUCCESS)
=
dbError(8989,1313,1515"SQLSetStmtOption()",
hstmt_select);

=09

UCHAR buf6[] =3D 8989,1313,1515"drop table
regressiontest"
;

=09

retcode =3D SQLExecDirect(hstmt, buf6,
7676,0F0F,5050sizeof(buf6));

7676,0F0F,5050if (retcode !=3D
SQL_SUCCESS)
dbError(8989,1313,1515"SQLExecDirect()",
hstmt);



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


7676,0F0F,5050const
7676,0F0F,5050int ArraySize =3D
0000,0000,FFFF1;

SQLUSMALLINT RowStatusArray[ArraySize];


2323,6E6E,2525// Set the array size to =
one.


SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_ARRAY_SIZE, (SQLPOINTER)
ArraySize, 0000,0000,FFFF0);

=09

2323,6E6E,2525// Why this construct =
??


SQLINTEGER csrType =3D SQL_CURSOR_KEYSET_DRIVEN;

=09

SQLSetStmtAttr(hstmt, SQL_ATTR_CURSOR_TYPE, (SQLPOINTER) =
csrType,
0000,0000,FFFF0);

SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_BIND_TYPE, =
SQL_BIND_BY_COLUMN,
0000,0000,FFFF0);

SQLSetStmtAttr(hstmt, SQL_ATTR_ROW_STATUS_PTR, RowStatusArray,
0000,0000,FFFF0);



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 |=09

40235 Düsseldorf | www.lollisoft.de




--Apple-Mail-1-888123249--

Re: Strange problem ?

am 24.01.2006 14:37:12 von Ludek Finstrle

> My wrappers code (AFTER calling SQLExecDirect(...)):
^^^^^^^^^^^^^^^^^^^^^^^^^^^
This could be the problem. You open cursor and then
you want change the type ...

I'm not expert in this question. I don't use ODBC frequently.

> // Why this construct ??
> SQLINTEGER csrType = SQL_CURSOR_KEYSET_DRIVEN;
>
> SQLSetStmtAttr(hstmt, SQL_ATTR_CURSOR_TYPE, (SQLPOINTER)
> csrType, 0);
>
> Dave's sample works with KEYSET_DRIVEN cursors.

Keyset driven cursor isn't full dynamic cursor (ODBC spec).
Keyset driven cursor doesn't detect added or deleted rows from
other transactions.

I'm sorry I can't help you more

Luf

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: Strange problem ?

am 24.01.2006 19:51:36 von Lothar Behrens

Am 24.01.2006 um 14:37 schrieb Ludek Finstrle:

>> My wrappers code (AFTER calling SQLExecDirect(...)):
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This could be the problem. You open cursor and then
> you want change the type ...
>
> I'm not expert in this question. I don't use ODBC frequently.

That didn't solved the problem, but I found it !

My last test was to get the current unixODBC source code. (2.2.11)
Building and installing that beast and reinstalling the original driver=20
07.03.0200 solved it.

There IS a problem in the 2.2.8 driver !

And my last update via SuSE YOU didn't pull that version.

That was the problem I really knew. But I didn't remember.

>
>> // Why this construct ??
>> SQLINTEGER csrType =3D SQL_CURSOR_KEYSET_DRIVEN;
>>
>> SQLSetStmtAttr(hstmt, SQL_ATTR_CURSOR_TYPE, (SQLPOINTER)
>> csrType, 0);
>>
>> Dave's sample works with KEYSET_DRIVEN cursors.
>
> Keyset driven cursor isn't full dynamic cursor (ODBC spec).
> Keyset driven cursor doesn't detect added or deleted rows from
> other transactions.

I know.

>
> I'm sorry I can't help you more
>
> Luf
>
> ---------------------------(end of=20
> broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
>
--
Lothar Behrens | Rapid Prototyping ...
Rosmarinstr 3 |=09
40235 Düsseldorf | www.lollisoft.de



---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match