From sirio.capizzi at prometeia.it Wed Nov 5 09:50:50 2008 From: sirio.capizzi at prometeia.it (Sirio Capizzi) Date: Wed Nov 5 09:51:00 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors Message-ID: <49115E6A.6030405@prometeia.it> Hi all, we have a problem using egenix mxODBC with a stored procedure using cursors. The scenario is the following: a Windows XP based client tries to call a stored procedure on a Microsoft SQL Server 2000 using python 2.5 and mxODBC 3.0.2. The procedure simply copies all the rows of a table to another one using cursors. The call succeeds but a random numer of rows are copied instead of the full table. We have tried with execute, executedirect and callproc. Execute and executedirect complete but only a random number of rows are copied. Callproc crashes and a windows error report dialog pops up saying that an error occured in mxodbc.pyd. We also tried .setconnectoption(SQL.CURSOR_TYPE,SQL.CURSOR_DYNAMIC) but with no results. Someone can help us? Thank you in advance. The stored procedure looks like the following, attaced you will find the odbc connection trace: USE [db3] GO /****** Oggetto: StoredProcedure [user].[CursorTest] Data script: 11/05/2008 08:44:39 ******/ SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure [user].[CursorTest] as truncate table db3.user.CursorTest_test declare @codicePaese varchar(100), @assetClass varchar(100), @nomeSocieta varchar(100), @description varchar(100), @codicePaesePrec varchar(100), @assetClassPrec varchar(100) set @codicePaesePrec = 'aaa' set @assetClassPrec = 'bbb' DECLARE cursore CURSOR FOR select CodicePaese, AssetClass, NomeSocieta, [Description] from db3..sourceTable order by codicepaese, assetclass, nomesocieta OPEN cursore FETCH NEXT FROM cursore INTO @codicePaese, @assetClass, @nomeSocieta, @description WHILE @@FETCH_STATUS = 0 BEGIN IF @codicePaese + '.' + @assetclass = @codicePaesePrec + '.' + @assetclassPrec BEGIN set @codicePaesePrec = @codicePaese set @assetclassPrec = @assetclass END ELSE BEGIN insert into db3.user.CursorTest_test (codicepaese, assetclass, nomesocieta, [description]) values(@codicePaese, @assetClass, @nomeSocieta, @description) set @codicePaesePrec = @codicePaese set @assetclassPrec = @assetclass END FETCH NEXT FROM cursore INTO @codicePaese, @assetClass, @nomeSocieta, @description END CLOSE cursore DEALLOCATE cursore -- SIRIO CAPIZZI Prometeia SpA Via G. Marconi, 43 40122 Bologna Italy -------------- next part -------------- provaodbc 1608-161c ENTER SQLAllocHandle SQLSMALLINT 1 SQLHANDLE 00000000 SQLHANDLE * 0098E984 provaodbc 1608-161c EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 1 SQLHANDLE 00000000 SQLHANDLE * 0x0098E984 ( 0x009a1788) provaodbc 1608-161c ENTER SQLSetEnvAttr SQLHENV 009A1788 SQLINTEGER 200 SQLPOINTER 0x00000003 SQLINTEGER 0 provaodbc 1608-161c EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS) SQLHENV 009A1788 SQLINTEGER 200 SQLPOINTER 0x00000003 (BADMEM) SQLINTEGER 0 provaodbc 1608-161c ENTER SQLAllocHandle SQLSMALLINT 2 SQLHANDLE 009A1788 SQLHANDLE * 00A967A8 provaodbc 1608-161c EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 2 SQLHANDLE 009A1788 SQLHANDLE * 0x00A967A8 ( 0x009a1830) provaodbc 1608-161c ENTER SQLConnectW HDBC 009A1830 WCHAR * 0x009A1938 [ -3] "db3\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 provaodbc 1608-161c EXIT SQLConnectW with return code 1 (SQL_SUCCESS_WITH_INFO) HDBC 009A1830 WCHAR * 0x009A1938 [ -3] "db3\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Il contesto di database ? stato sostituito con 'db3'. (5701) DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english. (5703) provaodbc 1608-161c ENTER SQLErrorW HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc 1608-161c EXIT SQLErrorW with return code 0 (SQL_SUCCESS) HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 (5701) WCHAR * 0x0021F674 [ 110] "[Microsoft][ODBC SQL Server Driver][SQL Server]Il contesto di database \ff stato sostituito con 'db3'." SWORD 511 SWORD * 0x0021FAC4 (110) provaodbc 1608-161c ENTER SQLErrorW HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc 1608-161c EXIT SQLErrorW with return code 0 (SQL_SUCCESS) HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 (5703) WCHAR * 0x0021F674 [ 86] "[Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english." SWORD 511 SWORD * 0x0021FAC4 (86) provaodbc 1608-161c ENTER SQLErrorW HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc 1608-161c EXIT SQLErrorW with return code 100 (SQL_NO_DATA_FOUND) HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc 1608-161c ENTER SQLGetInfoW HDBC 009A1830 UWORD 17 PTR 0x009A2328 SWORD 2048 SWORD * 0x0021F50C provaodbc 1608-161c EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 17 PTR 0x009A2328 [ 40] "Microsoft SQL Server" SWORD 2048 SWORD * 0x0021F50C (40) provaodbc 1608-161c ENTER SQLGetInfoW HDBC 009A1830 UWORD 18 PTR 0x009A2270 SWORD 2048 SWORD * 0x0021F0E8 provaodbc 1608-161c EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 18 PTR 0x009A2270 [ 20] "08.00.2039" SWORD 2048 SWORD * 0x0021F0E8 (20) provaodbc 1608-161c ENTER SQLGetInfoW HDBC 009A1830 UWORD 6 PTR 0x009A2270 SWORD 2048 SWORD * 0x0021F0E8 provaodbc 1608-161c EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 6 PTR 0x009A2270 [ 24] "SQLSRV32.DLL" SWORD 2048 SWORD * 0x0021F0E8 (24) provaodbc 1608-161c ENTER SQLGetInfoW HDBC 009A1830 UWORD 7 PTR 0x009A2270 SWORD 2048 SWORD * 0x0021F0E8 provaodbc 1608-161c EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 7 PTR 0x009A2270 [ 20] "03.85.1132" SWORD 2048 SWORD * 0x0021F0E8 (20) provaodbc 1608-161c ENTER SQLGetFunctions HDBC 009A1830 UWORD 1016 UWORD * 0x0021F504 provaodbc 1608-161c EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 1016 UWORD * 0x0021F504 (1) provaodbc 1608-161c ENTER SQLGetFunctions HDBC 009A1830 UWORD 1020 UWORD * 0x0021F504 provaodbc 1608-161c EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 1020 UWORD * 0x0021F504 (1) provaodbc 1608-161c ENTER SQLGetFunctions HDBC 009A1830 UWORD 58 UWORD * 0x0021F504 provaodbc 1608-161c EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 58 UWORD * 0x0021F504 (1) provaodbc 1608-161c ENTER SQLGetFunctions HDBC 009A1830 UWORD 1021 UWORD * 0x0021F504 provaodbc 1608-161c EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 1021 UWORD * 0x0021F504 (1) provaodbc 1608-161c ENTER SQLGetInfoW HDBC 009A1830 UWORD 81 PTR 0021F510 SWORD 1024 SWORD * 0x0021F508 provaodbc 1608-161c EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 81 PTR 0021F510 SWORD 1024 SWORD * 0x0021F508 (4) provaodbc 1608-161c ENTER SQLGetInfoW HDBC 009A1830 UWORD 46 PTR 0x0021F510 SWORD 1024 SWORD * 0x0021F508 provaodbc 1608-161c EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 46 PTR 0x0021F510 (2) SWORD 1024 SWORD * 0x0021F508 (2) provaodbc 1608-161c ENTER SQLSetConnectAttr SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x00000000 SQLINTEGER 0 provaodbc 1608-161c EXIT SQLSetConnectAttr with return code 0 (SQL_SUCCESS) SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x00000000 SQLINTEGER 0 provaodbc 1608-161c ENTER SQLGetConnectAttr SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x0021F4E0 SQLINTEGER 4 SQLINTEGER * 0x0021F4E4 provaodbc 1608-161c EXIT SQLGetConnectAttr with return code 0 (SQL_SUCCESS) SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x0021F4E0 SQLINTEGER 4 SQLINTEGER * 0x0021F4E4 (4) provaodbc 1608-161c ENTER SQLSetConnectAttr SQLHDBC 009A1830 SQLINTEGER 6 SQLPOINTER 0x00000002 SQLINTEGER 0 provaodbc 1608-161c EXIT SQLSetConnectAttr with return code 0 (SQL_SUCCESS) SQLHDBC 009A1830 SQLINTEGER 6 SQLPOINTER 0x00000002 (BADMEM) SQLINTEGER 0 provaodbc 1608-161c ENTER SQLAllocHandle SQLSMALLINT 3 SQLHANDLE 009A1830 SQLHANDLE * 00B19EEC provaodbc 1608-161c EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 3 SQLHANDLE 009A1830 SQLHANDLE * 0x00B19EEC ( 0x009a2298) provaodbc 1608-161c ENTER SQLFreeStmt HSTMT 009A2298 UWORD 3 provaodbc 1608-161c EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 009A2298 UWORD 3 provaodbc 1608-161c ENTER SQLFreeStmt HSTMT 009A2298 UWORD 0 provaodbc 1608-161c EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 009A2298 UWORD 0 provaodbc 1608-161c ENTER SQLExecDirect HSTMT 009A2298 UCHAR * 0x00B57BE8 [ 11] "CursorTest" SDWORD 11 provaodbc 1608-161c EXIT SQLExecDirect with return code 0 (SQL_SUCCESS) HSTMT 009A2298 UCHAR * 0x00B57BE8 [ 11] "CursorTest" SDWORD 11 provaodbc 1608-161c ENTER SQLNumResultCols HSTMT 009A2298 SWORD * 0x0021FCEC provaodbc 1608-161c EXIT SQLNumResultCols with return code 0 (SQL_SUCCESS) HSTMT 009A2298 SWORD * 0x0021FCEC (0) provaodbc 1608-161c ENTER SQLGetStmtAttr SQLHSTMT 009A2298 SQLINTEGER 14 SQLPOINTER 0x0021FCD4 SQLINTEGER 4 SQLINTEGER * 0x0021FCD8 provaodbc 1608-161c EXIT SQLGetStmtAttr with return code -1 (SQL_ERROR) SQLHSTMT 009A2298 SQLINTEGER 14 SQLPOINTER 0x0021FCD4 SQLINTEGER 4 SQLINTEGER * 0x0021FCD8 DIAG [24000] [Microsoft][Driver Manager ODBC] Stato del cursore non valido. (0) provaodbc 1608-161c ENTER SQLFreeStmt HSTMT 009A2298 UWORD 3 provaodbc 1608-161c EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 009A2298 UWORD 3 provaodbc 1608-161c ENTER SQLFreeHandle SQLSMALLINT 3 SQLHANDLE 009A2298 provaodbc 1608-161c EXIT SQLFreeHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 3 SQLHANDLE 009A2298 provaodbc 1608-161c ENTER SQLEndTran SQLSMALLINT 2 SQLHANDLE 009A1830 SQLSMALLINT 0 provaodbc 1608-161c EXIT SQLEndTran with return code 0 (SQL_SUCCESS) SQLSMALLINT 2 SQLHANDLE 009A1830 SQLSMALLINT 0 provaodbc 1608-161c ENTER SQLDisconnect HDBC 009A1830 provaodbc 1608-161c EXIT SQLDisconnect with return code 0 (SQL_SUCCESS) HDBC 009A1830 provaodbc 1608-161c ENTER SQLFreeHandle SQLSMALLINT 2 SQLHANDLE 009A1830 provaodbc 1608-161c EXIT SQLFreeHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 2 SQLHANDLE 009A1830 provaodbc 1608-161c ENTER SQLFreeHandle SQLSMALLINT 1 SQLHANDLE 009A1788 provaodbc 1608-161c EXIT SQLFreeHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 1 SQLHANDLE 009A1788 From mal at egenix.com Wed Nov 5 11:54:09 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 5 11:54:16 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <49115E6A.6030405@prometeia.it> References: <49115E6A.6030405@prometeia.it> Message-ID: <49117B51.8010009@egenix.com> On 2008-11-05 09:50, Sirio Capizzi wrote: > Hi all, > we have a problem using egenix mxODBC with a stored procedure using > cursors. The scenario is the following: a Windows XP based client tries > to call a stored procedure on a Microsoft SQL Server 2000 using python > 2.5 and mxODBC 3.0.2. The procedure simply copies all the rows of a > table to another one using cursors. The call succeeds but a random numer > of rows are copied instead of the full table. See below - there's an IF clause there that applies filtering. > We have tried with > execute, executedirect and callproc. Execute and executedirect complete > but only a random number of rows are copied. Callproc crashes and a > windows error report dialog pops up saying that an error occured in > mxodbc.pyd. Could you send us the Python script (or snippet) you used to trigger the segfault ? Segfaults in mxODBC itself are rare - segfaults in the underlying ODBC driver unfortunately not, but we always try to add work-arounds for these buggy drivers if possible, so feedback is appreciated. > We also tried > .setconnectoption(SQL.CURSOR_TYPE,SQL.CURSOR_DYNAMIC) but with no results. > > Someone can help us? Thank you in advance. > > The stored procedure looks like the following, attaced you will find the > odbc connection trace: > > USE [db3] > GO > /****** Oggetto: StoredProcedure [user].[CursorTest] Data script: > 11/05/2008 08:44:39 ******/ > SET ANSI_NULLS ON > GO > SET QUOTED_IDENTIFIER ON > GO > > ALTER procedure [user].[CursorTest] as > > truncate table db3.user.CursorTest_test > > > declare @codicePaese varchar(100), @assetClass varchar(100), > @nomeSocieta varchar(100), @description varchar(100), @codicePaesePrec > varchar(100), @assetClassPrec varchar(100) > > set @codicePaesePrec = 'aaa' > set @assetClassPrec = 'bbb' > > DECLARE cursore CURSOR > FOR > > select CodicePaese, AssetClass, NomeSocieta, [Description] > from db3..sourceTable > order by codicepaese, assetclass, nomesocieta > > OPEN cursore > > FETCH NEXT FROM cursore > INTO @codicePaese, @assetClass, @nomeSocieta, @description > > WHILE @@FETCH_STATUS = 0 > > BEGIN > > IF @codicePaese + '.' + @assetclass = @codicePaesePrec + '.' + > @assetclassPrec > BEGIN > set @codicePaesePrec = @codicePaese > set @assetclassPrec = @assetclass > END > ELSE The above IF will likely filter out a few rows. Is that intended ? > BEGIN > > > insert into db3.user.CursorTest_test (codicepaese, assetclass, > nomesocieta, [description]) > values(@codicePaese, @assetClass, @nomeSocieta, @description) > set @codicePaesePrec = @codicePaese > set @assetclassPrec = @assetclass > > END > > FETCH NEXT FROM cursore > INTO @codicePaese, @assetClass, @nomeSocieta, @description > > END > > CLOSE cursore > DEALLOCATE cursore Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From sirio.capizzi at prometeia.it Wed Nov 5 12:45:53 2008 From: sirio.capizzi at prometeia.it (Sirio Capizzi) Date: Wed Nov 5 12:45:58 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors Message-ID: <49118771.1090001@prometeia.it> Yes, the if clause is intended and the problem doesn't depend on it. The problem is that each time you execute the stored procedure you got a different numer of rows even if the procedure uses the same set of data. The python script we are using is the following: import mx.ODBC.Windows from mx.ODBC.Windows import SQL conn=mx.ODBC.Windows.Connect('db3','user','password') conn.setconnectoption(SQL.CURSOR_TYPE,SQL.CURSOR_DYNAMIC) cur = conn.cursor() cur.callproc('CursorTest') cur.close() conn.commit() The version of the SQL Server ODBC driver is 2000.85.1132.00 > On 2008-11-05 09:50, Sirio Capizzi wrote: > >/ Hi all, > />/ we have a problem using egenix mxODBC with a stored procedure using > />/ cursors. The scenario is the following: a Windows XP based client tries > />/ to call a stored procedure on a Microsoft SQL Server 2000 using python > />/ 2.5 and mxODBC 3.0.2. The procedure simply copies all the rows of a > />/ table to another one using cursors. The call succeeds but a random numer > />/ of rows are copied instead of the full table. > / > See below - there's an IF clause there that applies filtering. > > >/ We have tried with > />/ execute, executedirect and callproc. Execute and executedirect complete > />/ but only a random number of rows are copied. Callproc crashes and a > />/ windows error report dialog pops up saying that an error occured in > />/ mxodbc.pyd. > / > Could you send us the Python script (or snippet) you used to trigger the > segfault ? > > Segfaults in mxODBC itself are rare - segfaults in the underlying > ODBC driver unfortunately not, but we always try to add work-arounds > for these buggy drivers if possible, so feedback is appreciated. > > -- SIRIO CAPIZZI Prometeia SpA Via G. Marconi, 43 40122 Bologna Italy From mal at egenix.com Wed Nov 5 14:04:59 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 5 14:05:04 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <49118771.1090001@prometeia.it> References: <49118771.1090001@prometeia.it> Message-ID: <491199FB.7040205@egenix.com> On 2008-11-05 12:45, Sirio Capizzi wrote: > Yes, the if clause is intended and the problem doesn't depend on it. The > problem is that each time you execute the stored procedure you got a > different numer of rows even if the procedure uses the same set of data. Have you tried this in the SQL Server Management GUI ? Since the stored procedure runs entirely on the server side, I don't think that mxODBC or the ODBC driver can cause this behavior. > The python script we are using is the following: > > import mx.ODBC.Windows > from mx.ODBC.Windows import SQL > > conn=mx.ODBC.Windows.Connect('db3','user','password') > conn.setconnectoption(SQL.CURSOR_TYPE,SQL.CURSOR_DYNAMIC) The segfault is likely caused by the above option setting: SQL.CURSOR_TYPE is a *cursor* option, not a connection option, so you're adjusting some unknown option on the connection to some unknown value. BTW: Please don't change the SQL.CURSOR_TYPE value - mxODBC uses static cursors for efficiency and also to enable scrolling in result sets. > cur = conn.cursor() > cur.callproc('CursorTest') > cur.close() > > conn.commit() > > The version of the SQL Server ODBC driver is 2000.85.1132.00 > >> On 2008-11-05 09:50, Sirio Capizzi wrote: >> >/ Hi all, >> />/ we have a problem using egenix mxODBC with a stored procedure using >> />/ cursors. The scenario is the following: a Windows XP based client >> tries >> />/ to call a stored procedure on a Microsoft SQL Server 2000 using >> python >> />/ 2.5 and mxODBC 3.0.2. The procedure simply copies all the rows of a >> />/ table to another one using cursors. The call succeeds but a random >> numer >> />/ of rows are copied instead of the full table. / >> See below - there's an IF clause there that applies filtering. >> >> >/ We have tried with >> />/ execute, executedirect and callproc. Execute and executedirect >> complete >> />/ but only a random number of rows are copied. Callproc crashes and a >> />/ windows error report dialog pops up saying that an error occured in >> />/ mxodbc.pyd. / >> Could you send us the Python script (or snippet) you used to trigger the >> segfault ? >> >> Segfaults in mxODBC itself are rare - segfaults in the underlying >> ODBC driver unfortunately not, but we always try to add work-arounds >> for these buggy drivers if possible, so feedback is appreciated. >> >> > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From sirio.capizzi at prometeia.it Wed Nov 5 14:52:28 2008 From: sirio.capizzi at prometeia.it (Sirio Capizzi) Date: Wed Nov 5 14:52:33 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <491199FB.7040205@egenix.com> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> Message-ID: <4911A51C.90608@prometeia.it> M.-A. Lemburg ha scritto: > On 2008-11-05 12:45, Sirio Capizzi wrote: > > Have you tried this in the SQL Server Management GUI ? > > Since the stored procedure runs entirely on the server > side, I don't think that mxODBC or the ODBC driver > can cause this behavior. > Yes, I have tried it on the server side and it works correctly. Moreover on the same client was installed mxODBC 2.0.6 for python 2.3 and it worked fine too. After upgrading to python 2.5 and mxODBC 3.0.2 we got this problem but only on stored procedures using cursors (the others work fine). So I think that this behavior is caused by the new mxODBC library. > The segfault is likely caused by the above option setting: > SQL.CURSOR_TYPE is a *cursor* option, not a connection > option, so you're adjusting some unknown option on the > connection to some unknown value. > > BTW: Please don't change the SQL.CURSOR_TYPE value - mxODBC > uses static cursors for efficiency and also to enable > scrolling in result sets. > You are right. However the connectionoption doesn't influence the behavior of the callproc function. In fact without this line python still crashes. -- SIRIO CAPIZZI Prometeia SpA Via G. Marconi, 43 40122 Bologna Italy e-mail : sirio.capizzi@prometeia.it phone : +39 051 6480911 --------------------------------------------------------------------------- Il contenuto e gli allegati di questo messaggio sono strettamente confidenziali, e ne sono vietati la diffusione, la riproduzione e l'uso non autorizzato. Il suo contenuto non costituisce impegno da parte della Societ? salvo accordo scritto tra quest'ultima ed il destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La preghiamo di comunicare immediatamente al mittente l'errata ricezione e di distruggere quanto ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non rivelare il contenuto della corrispondenza tra altri soggetti, salvo pi? grave illecito, ed espone il responsabile alle relative conseguenze. This e-mail (and any attachment(s)) is strictly confidential and for use only by intended recipient(s). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. The content of this e-mail does not constitute a commitment by the Company except where provided for in a written agreement between this e-mail addressee and the Company. If you are not an intended recipient(s), please notify the sender promptly and destroy this message and its attachments without reading or saving it in any manner. Any non authorized use of the content of this message constitutes a violation of the obligation to abstain from learning of the correspondence among other subjects, except for more serious offence, and exposes the person responsible to the relevant consequences. --------------------------------------------------------------------------- From mal at egenix.com Wed Nov 5 15:12:41 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 5 15:12:45 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <4911A51C.90608@prometeia.it> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> <4911A51C.90608@prometeia.it> Message-ID: <4911A9D9.3080404@egenix.com> On 2008-11-05 14:52, Sirio Capizzi wrote: > > M.-A. Lemburg ha scritto: >> On 2008-11-05 12:45, Sirio Capizzi wrote: >> Have you tried this in the SQL Server Management GUI ? >> >> Since the stored procedure runs entirely on the server >> side, I don't think that mxODBC or the ODBC driver >> can cause this behavior. >> > Yes, I have tried it on the server side and it works correctly. Moreover > on the same client was installed mxODBC 2.0.6 for python 2.3 and it > worked fine too. After upgrading to python 2.5 and mxODBC 3.0.2 we got > this problem but only on stored procedures using cursors (the others > work fine). So I think that this behavior is caused by the new mxODBC > library. mxODBC 3.0 tries to use the ODBC 3.x API where possible, so that may explain why you are seeing different behavior compared to mxODBC 2.0. The SQL Server 2000 ODBC driver is rather old, so it's possible that it doesn't support the ODBC 3.x API all that well. However, our tests pass just fine for that driver as well, but AFAIK we don't use cursors in the tested stored procedures, so that's something to add to the test suite. >> The segfault is likely caused by the above option setting: >> SQL.CURSOR_TYPE is a *cursor* option, not a connection >> option, so you're adjusting some unknown option on the >> connection to some unknown value. >> >> BTW: Please don't change the SQL.CURSOR_TYPE value - mxODBC >> uses static cursors for efficiency and also to enable >> scrolling in result sets. > > You are right. However the connectionoption doesn't influence the > behavior of the callproc function. In fact without this line python > still crashes. Could you send us an ODBC trace that shows the crash (ie. stops after the crash) ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From sirio.capizzi at prometeia.it Wed Nov 5 15:55:49 2008 From: sirio.capizzi at prometeia.it (Sirio Capizzi) Date: Wed Nov 5 15:55:59 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <4911A9D9.3080404@egenix.com> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> <4911A51C.90608@prometeia.it> <4911A9D9.3080404@egenix.com> Message-ID: <4911B3F5.7060106@prometeia.it> M.-A. Lemburg ha scritto: > > mxODBC 3.0 tries to use the ODBC 3.x API where possible, > so that may explain why you are seeing different behavior > compared to mxODBC 2.0. > > The SQL Server 2000 ODBC driver is rather old, so it's possible > that it doesn't support the ODBC 3.x API all that well. > > However, our tests pass just fine for that driver as well, but > AFAIK we don't use cursors in the tested stored procedures, so > that's something to add to the test suite. > Very interesting... It is possible to force mxODBC to use only the ODBC 2.0 API? There are newer drivers for SQL Server 2000? > > Could you send us an ODBC trace that shows the crash (ie. stops > after the crash) ? Of course, you will find it in the attachment. Thank you for your help. -- SIRIO CAPIZZI Prometeia SpA Via G. Marconi, 43 40122 Bologna Italy e-mail : sirio.capizzi@prometeia.it phone : +39 051 6480911 --------------------------------------------------------------------------- Il contenuto e gli allegati di questo messaggio sono strettamente confidenziali, e ne sono vietati la diffusione, la riproduzione e l'uso non autorizzato. Il suo contenuto non costituisce impegno da parte della Societ? salvo accordo scritto tra quest'ultima ed il destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La preghiamo di comunicare immediatamente al mittente l'errata ricezione e di distruggere quanto ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia utilizzo non autorizzato del contenuto di questo messaggio costituisce violazione dell'obbligo di non rivelare il contenuto della corrispondenza tra altri soggetti, salvo pi? grave illecito, ed espone il responsabile alle relative conseguenze. This e-mail (and any attachment(s)) is strictly confidential and for use only by intended recipient(s). Any use, distribution, reproduction or disclosure by any other person is strictly prohibited. The content of this e-mail does not constitute a commitment by the Company except where provided for in a written agreement between this e-mail addressee and the Company. If you are not an intended recipient(s), please notify the sender promptly and destroy this message and its attachments without reading or saving it in any manner. Any non authorized use of the content of this message constitutes a violation of the obligation to abstain from learning of the correspondence among other subjects, except for more serious offence, and exposes the person responsible to the relevant consequences. --------------------------------------------------------------------------- -------------- next part -------------- provaodbc cb4-1678 ENTER SQLAllocHandle SQLSMALLINT 1 SQLHANDLE 00000000 SQLHANDLE * 0098E984 provaodbc cb4-1678 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 1 SQLHANDLE 00000000 SQLHANDLE * 0x0098E984 ( 0x009a1788) provaodbc cb4-1678 ENTER SQLSetEnvAttr SQLHENV 009A1788 SQLINTEGER 200 SQLPOINTER 0x00000003 SQLINTEGER 0 provaodbc cb4-1678 EXIT SQLSetEnvAttr with return code 0 (SQL_SUCCESS) SQLHENV 009A1788 SQLINTEGER 200 SQLPOINTER 0x00000003 (BADMEM) SQLINTEGER 0 provaodbc cb4-1678 ENTER SQLAllocHandle SQLSMALLINT 2 SQLHANDLE 009A1788 SQLHANDLE * 00A96758 provaodbc cb4-1678 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 2 SQLHANDLE 009A1788 SQLHANDLE * 0x00A96758 ( 0x009a1830) provaodbc cb4-1678 ENTER SQLConnectW HDBC 009A1830 WCHAR * 0x009A1938 [ -3] "db3\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 provaodbc cb4-1678 EXIT SQLConnectW with return code 1 (SQL_SUCCESS_WITH_INFO) HDBC 009A1830 WCHAR * 0x009A1938 [ -3] "db3\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 WCHAR * 0x745E4EC8 [ -3] "******\ 0" SWORD -3 DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Il contesto di database ? stato sostituito con 'db3'. (5701) DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english. (5703) provaodbc cb4-1678 ENTER SQLErrorW HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc cb4-1678 EXIT SQLErrorW with return code 0 (SQL_SUCCESS) HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 (5701) WCHAR * 0x0021F674 [ 110] "[Microsoft][ODBC SQL Server Driver][SQL Server]Il contesto di database \ff stato sostituito con 'db3'." SWORD 511 SWORD * 0x0021FAC4 (110) provaodbc cb4-1678 ENTER SQLErrorW HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc cb4-1678 EXIT SQLErrorW with return code 0 (SQL_SUCCESS) HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 (5703) WCHAR * 0x0021F674 [ 86] "[Microsoft][ODBC SQL Server Driver][SQL Server]Changed language setting to us_english." SWORD 511 SWORD * 0x0021FAC4 (86) provaodbc cb4-1678 ENTER SQLErrorW HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc cb4-1678 EXIT SQLErrorW with return code 100 (SQL_NO_DATA_FOUND) HENV 009A1788 HDBC 009A1830 HSTMT 00000000 WCHAR * 0x0021FA74 (NYI) SDWORD * 0x0021FAC0 WCHAR * 0x0021F674 SWORD 511 SWORD * 0x0021FAC4 provaodbc cb4-1678 ENTER SQLGetInfoW HDBC 009A1830 UWORD 17 PTR 0x009A2328 SWORD 2048 SWORD * 0x0021F50C provaodbc cb4-1678 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 17 PTR 0x009A2328 [ 40] "Microsoft SQL Server" SWORD 2048 SWORD * 0x0021F50C (40) provaodbc cb4-1678 ENTER SQLGetInfoW HDBC 009A1830 UWORD 18 PTR 0x009A2270 SWORD 2048 SWORD * 0x0021F0E8 provaodbc cb4-1678 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 18 PTR 0x009A2270 [ 20] "08.00.2039" SWORD 2048 SWORD * 0x0021F0E8 (20) provaodbc cb4-1678 ENTER SQLGetInfoW HDBC 009A1830 UWORD 6 PTR 0x009A2270 SWORD 2048 SWORD * 0x0021F0E8 provaodbc cb4-1678 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 6 PTR 0x009A2270 [ 24] "SQLSRV32.DLL" SWORD 2048 SWORD * 0x0021F0E8 (24) provaodbc cb4-1678 ENTER SQLGetInfoW HDBC 009A1830 UWORD 7 PTR 0x009A2270 SWORD 2048 SWORD * 0x0021F0E8 provaodbc cb4-1678 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 7 PTR 0x009A2270 [ 20] "03.85.1132" SWORD 2048 SWORD * 0x0021F0E8 (20) provaodbc cb4-1678 ENTER SQLGetFunctions HDBC 009A1830 UWORD 1016 UWORD * 0x0021F504 provaodbc cb4-1678 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 1016 UWORD * 0x0021F504 (1) provaodbc cb4-1678 ENTER SQLGetFunctions HDBC 009A1830 UWORD 1020 UWORD * 0x0021F504 provaodbc cb4-1678 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 1020 UWORD * 0x0021F504 (1) provaodbc cb4-1678 ENTER SQLGetFunctions HDBC 009A1830 UWORD 58 UWORD * 0x0021F504 provaodbc cb4-1678 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 58 UWORD * 0x0021F504 (1) provaodbc cb4-1678 ENTER SQLGetFunctions HDBC 009A1830 UWORD 1021 UWORD * 0x0021F504 provaodbc cb4-1678 EXIT SQLGetFunctions with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 1021 UWORD * 0x0021F504 (1) provaodbc cb4-1678 ENTER SQLGetInfoW HDBC 009A1830 UWORD 81 PTR 0021F510 SWORD 1024 SWORD * 0x0021F508 provaodbc cb4-1678 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 81 PTR 0021F510 SWORD 1024 SWORD * 0x0021F508 (4) provaodbc cb4-1678 ENTER SQLGetInfoW HDBC 009A1830 UWORD 46 PTR 0x0021F510 SWORD 1024 SWORD * 0x0021F508 provaodbc cb4-1678 EXIT SQLGetInfoW with return code 0 (SQL_SUCCESS) HDBC 009A1830 UWORD 46 PTR 0x0021F510 (2) SWORD 1024 SWORD * 0x0021F508 (2) provaodbc cb4-1678 ENTER SQLSetConnectAttr SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x00000000 SQLINTEGER 0 provaodbc cb4-1678 EXIT SQLSetConnectAttr with return code 0 (SQL_SUCCESS) SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x00000000 SQLINTEGER 0 provaodbc cb4-1678 ENTER SQLGetConnectAttr SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x0021F4E0 SQLINTEGER 4 SQLINTEGER * 0x0021F4E4 provaodbc cb4-1678 EXIT SQLGetConnectAttr with return code 0 (SQL_SUCCESS) SQLHDBC 009A1830 SQLINTEGER 102 SQLPOINTER 0x0021F4E0 SQLINTEGER 4 SQLINTEGER * 0x0021F4E4 (4) provaodbc cb4-1678 ENTER SQLAllocHandle SQLSMALLINT 3 SQLHANDLE 009A1830 SQLHANDLE * 00B19EEC provaodbc cb4-1678 EXIT SQLAllocHandle with return code 0 (SQL_SUCCESS) SQLSMALLINT 3 SQLHANDLE 009A1830 SQLHANDLE * 0x00B19EEC ( 0x009a2270) provaodbc cb4-1678 ENTER SQLFreeStmt HSTMT 009A2270 UWORD 3 provaodbc cb4-1678 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 009A2270 UWORD 3 provaodbc cb4-1678 ENTER SQLFreeStmt HSTMT 009A2270 UWORD 0 provaodbc cb4-1678 EXIT SQLFreeStmt with return code 0 (SQL_SUCCESS) HSTMT 009A2270 UWORD 0 provaodbc cb4-1678 ENTER SQLPrepare HSTMT 009A2270 UCHAR * 0x00A55C90 [ 18] "{call CursorTest}" SDWORD 18 provaodbc cb4-1678 EXIT SQLPrepare with return code 0 (SQL_SUCCESS) HSTMT 009A2270 UCHAR * 0x00A55C90 [ 18] "{call CursorTest}" SDWORD 18 provaodbc cb4-1678 ENTER SQLNumParams HSTMT 009A2270 SWORD * 0x0021FCA8 provaodbc cb4-1678 EXIT SQLNumParams with return code 0 (SQL_SUCCESS) HSTMT 009A2270 SWORD * 0x0021FCA8 (0) provaodbc cb4-1678 ENTER SQLExecute HSTMT 009A2270 provaodbc cb4-1678 EXIT SQLExecute with return code 0 (SQL_SUCCESS) HSTMT 009A2270 provaodbc cb4-1678 ENTER SQLNumResultCols HSTMT 009A2270 SWORD * 0x0021FCCC provaodbc cb4-1678 EXIT SQLNumResultCols with return code 0 (SQL_SUCCESS) HSTMT 009A2270 SWORD * 0x0021FCCC (0) provaodbc cb4-1678 ENTER SQLGetStmtAttr SQLHSTMT 009A2270 SQLINTEGER 14 SQLPOINTER 0x0021FCB4 SQLINTEGER 4 SQLINTEGER * 0x0021FCB8 provaodbc cb4-1678 EXIT SQLGetStmtAttr with return code -1 (SQL_ERROR) SQLHSTMT 009A2270 SQLINTEGER 14 SQLPOINTER 0x0021FCB4 SQLINTEGER 4 SQLINTEGER * 0x0021FCB8 DIAG [24000] [Microsoft][Driver Manager ODBC] Stato del cursore non valido. (0) From mal at egenix.com Wed Nov 5 16:04:08 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 5 16:04:12 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <4911B3F5.7060106@prometeia.it> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> <4911A51C.90608@prometeia.it> <4911A9D9.3080404@egenix.com> <4911B3F5.7060106@prometeia.it> Message-ID: <4911B5E8.7020700@egenix.com> On 2008-11-05 15:55, Sirio Capizzi wrote: > > > M.-A. Lemburg ha scritto: >> >> mxODBC 3.0 tries to use the ODBC 3.x API where possible, >> so that may explain why you are seeing different behavior >> compared to mxODBC 2.0. >> >> The SQL Server 2000 ODBC driver is rather old, so it's possible >> that it doesn't support the ODBC 3.x API all that well. >> >> However, our tests pass just fine for that driver as well, but >> AFAIK we don't use cursors in the tested stored procedures, so >> that's something to add to the test suite. >> > Very interesting... It is possible to force mxODBC to use only the ODBC > 2.0 API? There are newer drivers for SQL Server 2000? No that's not possible without patching mxODBC. The ODBC manager will normally translate between the application and the driver, however, it only does this if the driver itself advertises itself as being a 2.0 driver. We'll setup a few new tests to try to reproduce the problem. >> Could you send us an ODBC trace that shows the crash (ie. stops >> after the crash) ? > Of course, you will find it in the attachment. Thank you for your help. Thanks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Wed Nov 5 17:25:08 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Nov 5 17:25:12 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <4911B5E8.7020700@egenix.com> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> <4911A51C.90608@prometeia.it> <4911A9D9.3080404@egenix.com> <4911B3F5.7060106@prometeia.it> <4911B5E8.7020700@egenix.com> Message-ID: <4911C8E4.6060209@egenix.com> M.-A. Lemburg wrote: > On 2008-11-05 15:55, Sirio Capizzi wrote: >> >> M.-A. Lemburg ha scritto: >>> mxODBC 3.0 tries to use the ODBC 3.x API where possible, >>> so that may explain why you are seeing different behavior >>> compared to mxODBC 2.0. >>> >>> The SQL Server 2000 ODBC driver is rather old, so it's possible >>> that it doesn't support the ODBC 3.x API all that well. >>> >>> However, our tests pass just fine for that driver as well, but >>> AFAIK we don't use cursors in the tested stored procedures, so >>> that's something to add to the test suite. >>> >> Very interesting... It is possible to force mxODBC to use only the ODBC >> 2.0 API? There are newer drivers for SQL Server 2000? > > No that's not possible without patching mxODBC. > > The ODBC manager will normally translate between the application and the > driver, however, it only does this if the driver itself advertises itself > as being a 2.0 driver. > > We'll setup a few new tests to try to reproduce the problem. We've added a test similar to what you're doing to out suite, but cannot reproduce the problem: Loaded mx.ODBC.Windows version 3.0.2 Testing package mx.ODBC.Windows version: 3.0.2 compiled with Unicode support using Python version: 2.5 Test suite: Connecting to the database. Connected to DSN DSN: sqlserver; Database: master; Server: PICASSO; User: dbo; DBMS: Microsoft SQL Server; Version: 08.00.0760; ODBC driver: SQLSRV32.DLL 03.85.1132; ODBC Version: 03.52 String encoding used by mxODBC: utf-8 StoredProcedureTest: executing create table mxODBC0001 (col1 int, col2 int) StoredProcedureTest: executing CREATE PROCEDURE sp_mxODBC0001 AS DECLARE @var1 int, @var2 int DECLARE cursor1 CURSOR FOR SELECT col1, col2 FROM mxODBC0001 ORDER BY col1 OPEN cursor1 FETCH NEXT FROM cursor1 INTO @var1, @var2 WHILE @@FETCH_STATUS = 0 BEGIN SELECT @var1 AS col1, @var2 AS col2 FETCH NEXT FROM cursor1 INTO @var1, @var2 END CLOSE cursor1 DEALLOCATE cursor1 SP: Cursors in procedures : function supported Disconnecting. Note that we're using the same ODBC driver version. Please check whether the SQL Server version also matches yours. >>> Could you send us an ODBC trace that shows the crash (ie. stops >>> after the crash) ? >> Of course, you will find it in the attachment. Thank you for your help. > > Thanks. The log indicates that the cursor state becomes invalid after having called the procedure. However, that should normally not result in a segfault. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 05 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Thu Nov 6 12:22:33 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Nov 6 12:22:38 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <4912C095.4020607@prometeia.it> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> <4911A51C.90608@prometeia.it> <4911A9D9.3080404@egenix.com> <4911B3F5.7060106@prometeia.it> <4911B5E8.7020700@egenix.com> <4911C8E4.6060209@egenix.com> <4912C095.4020607@prometeia.it> Message-ID: <4912D379.1030807@egenix.com> On 2008-11-06 11:01, Sirio Capizzi wrote: > I have checked the version of our DBMS and it is 8.00.2039. Hmm, looks like we're missing some service pack on ours. But then: your version should have fewer bugs - at least in theory. > Moreover I have done some tests using your stored procedure and another > one that is more similar to our situation: in every case the callproc > function crashes. I have attached the related odbc log files > SQL_sb_XXX_callproc_crash.log. More important for me is resolving the > problem with the random number of rows that are copied using the stored > procedure. So I have have done some tests using the followings table and > stored procedure: > > create table mxODBC0002(col1 int primary key,col2 int) > > CREATE PROCEDURE sp_mxODBC0002 AS > DECLARE @var1 int, @var2 int > DECLARE cursor1 CURSOR FOR > SELECT col1, col2 FROM mxODBC0001 > ORDER BY col1 > OPEN cursor1 > FETCH NEXT FROM cursor1 > INTO @var1, @var2 > WHILE @@FETCH_STATUS = 0 > BEGIN > insert into mxODBC0002 values (@var1, @var2) > FETCH NEXT FROM cursor1 > INTO @var1, @var2 > END > CLOSE cursor1 > DEALLOCATE cursor1 > > The table mxODBC0001 is the same of your previous mail. Using the new > simplified stored procedure the strange behavior continues to exist but > sometimes all rows are copied in the destination table. I have attached > two logs regarding this problem: SQL_sp_mxODBC0002_all_rows.LOG is the > log when the insertion completes sucessfully whereas > SQL_sp_mxODBC0002_some_rows.LOG is a log when only some rows are > inserted in the destination tables. I think that this is the simplest > scenario representing our situation and I hope that these logs can help > you in identifying the problem. We have added a similar test to our test suite and ran the test several times. All passed and no crashes. I've also had a look at the ODBC log and all I could find is the same problem that you find in the crashing ones: the cursor state is always invalid after you call the procedure. I can't tell from here, but this looks a lot like a problem in the ODBC driver or your setup. > I can provide you with more information if you need it. I have read on > the manual that the library can be compiled in a debug mode. Where can I > found such a library? If you can give me this type of library I can send > you the logs. We can't reproduce the problem with our setup and have already invested a fair amount of time into trying to help you with this without being able to really determine a problem in mxODBC. As a result, we have to ask you to get a support ticket(s) to continue working on your problem: http://www.egenix.com/services/support/ We can then provide you with a special debug build of mxODBC and analyze the logs it generates. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 06 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From mal at egenix.com Thu Nov 6 15:53:50 2008 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Nov 6 15:53:54 2008 Subject: [egenix-users] Impossible to correct execute stored procedure using cursors In-Reply-To: <4912D379.1030807@egenix.com> References: <49118771.1090001@prometeia.it> <491199FB.7040205@egenix.com> <4911A51C.90608@prometeia.it> <4911A9D9.3080404@egenix.com> <4911B3F5.7060106@prometeia.it> <4911B5E8.7020700@egenix.com> <4911C8E4.6060209@egenix.com> <4912C095.4020607@prometeia.it> <4912D379.1030807@egenix.com> Message-ID: <491304FE.8080102@egenix.com> On 2008-11-06 12:22, M.-A. Lemburg wrote: > On 2008-11-06 11:01, Sirio Capizzi wrote: >> I have checked the version of our DBMS and it is 8.00.2039. > > Hmm, looks like we're missing some service pack on ours. But then: your > version should have fewer bugs - at least in theory. FYI: We've upgraded to SP4 (8.00.2039) now, but still can't recreate the problem. >> Moreover I have done some tests using your stored procedure and another >> one that is more similar to our situation: in every case the callproc >> function crashes. I have attached the related odbc log files >> SQL_sb_XXX_callproc_crash.log. More important for me is resolving the >> problem with the random number of rows that are copied using the stored >> procedure. So I have have done some tests using the followings table and >> stored procedure: >> >> create table mxODBC0002(col1 int primary key,col2 int) >> >> CREATE PROCEDURE sp_mxODBC0002 AS >> DECLARE @var1 int, @var2 int >> DECLARE cursor1 CURSOR FOR >> SELECT col1, col2 FROM mxODBC0001 >> ORDER BY col1 >> OPEN cursor1 >> FETCH NEXT FROM cursor1 >> INTO @var1, @var2 >> WHILE @@FETCH_STATUS = 0 >> BEGIN >> insert into mxODBC0002 values (@var1, @var2) >> FETCH NEXT FROM cursor1 >> INTO @var1, @var2 >> END >> CLOSE cursor1 >> DEALLOCATE cursor1 >> >> The table mxODBC0001 is the same of your previous mail. Using the new >> simplified stored procedure the strange behavior continues to exist but >> sometimes all rows are copied in the destination table. I have attached >> two logs regarding this problem: SQL_sp_mxODBC0002_all_rows.LOG is the >> log when the insertion completes sucessfully whereas >> SQL_sp_mxODBC0002_some_rows.LOG is a log when only some rows are >> inserted in the destination tables. I think that this is the simplest >> scenario representing our situation and I hope that these logs can help >> you in identifying the problem. > > We have added a similar test to our test suite and ran the test > several times. All passed and no crashes. > > I've also had a look at the ODBC log and all I could find is the > same problem that you find in the crashing ones: the cursor state > is always invalid after you call the procedure. > > I can't tell from here, but this looks a lot like a problem in the > ODBC driver or your setup. > >> I can provide you with more information if you need it. I have read on >> the manual that the library can be compiled in a debug mode. Where can I >> found such a library? If you can give me this type of library I can send >> you the logs. > > We can't reproduce the problem with our setup and have already invested > a fair amount of time into trying to help you with this without being able > to really determine a problem in mxODBC. > > As a result, we have to ask you to get a support ticket(s) to continue > working on your problem: > > http://www.egenix.com/services/support/ > > We can then provide you with a special debug build of mxODBC > and analyze the logs it generates. > > Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 06 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 From info at egenix.com Wed Nov 12 16:38:37 2008 From: info at egenix.com (eGenix Team: M.-A. Lemburg) Date: Wed Nov 12 16:41:27 2008 Subject: [egenix-users] ANN: eGenix mxODBC Connect - Python Database Interface 0.9.3 (beta) Message-ID: <491AF87D.5040802@egenix.com> ________________________________________________________________________ ANNOUNCING eGenix.com mxODBC Connect Python Database Interface Version 0.9.3 (beta) Our new client-server product for connecting Python applications to relational databases - from all major platforms This announcement is also available on our web-site for online reading: http://www.egenix.com/company/news/eGenix-mxODBC-Connect-0.9.3-beta.html ________________________________________________________________________ INTRODUCTION The mxODBC Connect Database Interface for Python allows users to easily connect Python applications to all major databases on the market today in a highly portable and convenient way. Unlike our mxODBC Python extension, mxODBC Connect is designed as client-server application, so you no longer need to find production quality ODBC drivers for all the platforms you target with your Python application. Instead you use an easy to install Python client library which connects directly to the mxODBC Connect database server over the network. This makes mxODBC Connect the ideal basis for writing cross-platform database programs and utilities in Python, especially if you run applications that need to communicate with databases such as MS SQL Server and MS Access, Oracle Database, IBM DB2 and Informix, Sybase ASE and Sybase Anywhere, MySQL, PostgreSQL, SAP MaxDB and many more, that run on Windows or Linux machines. By removing the need to install and configure ODBC drivers on the client side, mxODBC Connect greatly simplifies setup and configuration of database driven client applications, while at the same time making the network communication between client and database server more efficient and more secure. For more information, please have a look at the product page: http://www.egenix.com/products/python/mxODBCConnect/ ________________________________________________________________________ NEWS mxODBC Connect 0.9.3 is the third public beta release of our new mxODBC Connect product. With this release we have improved the performance of mxODBC Connect significantly and achieved an up to 6 times better performance for a typical multi-tier application that runs on Linux and connects to a MS SQL Server database running on a Windows host, compared to the same application using mxODBC and the FreeTDS ODBC driver. mxODBC Connect 0.9.3 now comes with added optional compression of all network traffic and fixes two bugs found in the 0.9.2 beta release: a missing Windows DLL in the Windows installer and a problem with fail-over using SSL-enabled connections. We expect this to be last beta release before the 1.0.0 final release. *SPECIAL OFFER* If you would like to participate in the beta as tester, please see our beta program page: http://www.egenix.com/products/python/mxODBCConnect/beta.html In order to make participation in the beta program more interesting for our users, we will be giving out *20% discount coupons* to all participants who report back bugs in the product. ________________________________________________________________________ DOWNLOADS The download archives as well as instructions for installation and configuration of the product can be found on the product page: http://www.egenix.com/products/python/mxODBCConnect/ _______________________________________________________________________ SUPPORT Commercial support for this product is available from eGenix.com. Please see http://www.egenix.com/services/support/ for details about our support offerings. Enjoy, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 12 2008) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ :::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611