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 ?
|
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: