From d-arntson at uchicago.edu Mon Jan 3 18:13:54 2011 From: d-arntson at uchicago.edu (Dale Arntson) Date: Tue Jan 4 01:14:02 2011 Subject: [egenix-users] Problem with mxodbc 3.1 and Sybase 15.5 In-Reply-To: <4D143673.6000609@uchicago.edu> References: slrnhvksl1.r36.aclark@aclark.aclark.net <4D13ABBD.8020705@uchicago.edu> <4D13AF01.7000003@egenix.com> <4D143673.6000609@uchicago.edu> Message-ID: <4D226642.80603@uchicago.edu> Hi All, I haven't heard back from anyone yet, so I thought I would give any Sybase 15 users out there some code that would make it easier to replicate my problem by cutting and pasting. Just replace the 'xxx's with the proper dsn info. For this demo, I am using a Sybase ASE ODBC driver (version 15.00.00.50, 32 bit) on Windows XP against a Sybase 15.5 ASE database. import mx.ODBC.Windows import traceback class db_class: def __init__(self): datasource = 'xxx' user = 'xxx' password = 'xxx' self.dsn = "dsn=%s;uid=%s;pwd=%s" % (datasource, user, password) self.con = None self.cur = None def open(self): self.con = mx.ODBC.Windows.DriverConnect(self.dsn) self.con.bindmethod = mx.ODBC.Windows.BIND_USING_SQLTYPE self.cur = self.con.cursor() self.cur.executedirect("set chained off") def close(self): self.con.commit() self.cur.close() self.con.close() def create_table(db): db.cur.tables(table='friend') if db.cur.fetchone(): db.cur.executedirect('drop table friend') sql = "create table friend ( " \ "name varchar(20) not null, " \ "age smallint null, " \ "birthdate datetime null, " \ "favorite_beer varchar(20) null)" db.cur.executedirect(sql) def insert_data(db): rows = [['Stephanie', 28, '06/09/1982', 'Budwiser'], ['Raphael', 60, '01/16/50', 'Corona'], ['Johanna', 50, '09/23/1960', 'Pilsner']] sql = "insert into friend values (?,?,?,?)" for r in rows: print "Inserting %s" % r[0] db.cur.executedirect(sql,r) db.con.commit() def update_data(db): rows = [[28, '06/09/1982', None, 'Stephanie'], [60, None, 'Corona', 'Raphael'], [None, '09/23/1960', 'Pilsner', 'Johanna']] sql = "Update friend set age = ?, birthdate = ?, " \ "favorite_beer = ? where name = ?" for r in rows: print "Updating %s" % r[3] db.cur.executedirect(sql,r) db.con.commit() Now, using the above code, as expected, I can do the following: >>> db = db_class() >>> db.open() >>> create_table(db) >>> insert_data(db) Inserting Stephanie Inserting Raphael Inserting Johanna However, when I try to update my table by nullifying some of the columns, I get an error. I can nullify a varchar, and a datetime column just fine. But, when I try to nullify a smallint column, I get an error: >>> update_data(db) Updating Stephanie Updating Raphael Updating Johanna Traceback (most recent call last): File "", line 1, in File "c:\dale\dev\gbs\test\code\grin\python-49AGef.py", line 57, in update_data mx.ODBC.Error.ProgrammingError: ('42000', 257, "[Sybase][ODBC Driver][Adaptive Server Enterprise]Implicit conversion from datatype 'CHAR' to 'SMALLINT' is not allowed. Use the CONVERT function to run this query.\n", 8396) The Sybase odbc driver seems to think that age = None is a char, when, of course, it should be a null. I get this error using the following cursor.execute*() methods and connection.bindmethod values: .executedirect() and BIND_USING_SQLTYPE (as in the above code) .executedirect() and BIND_USING_PYTHONTYPE .execute() and BIND_USING_PYTHONTYPE However, when I change the above code to use: .execute() and BIND_USING_SQLTYPE to do the update, I get a different error: >>> update_data(db) Updating Stephanie Updating Raphael Traceback (most recent call last): File "", line 1, in File "c:\dale\dev\gbs\test\code\grin\python-49ATol.py", line 57, in update_data mx.ODBC.Error.ProgrammingError: ('ZZZZZ', 3814, '[Sybase][ODBC Driver][Adaptive Server Enterprise]The parameter of type 61 did not have a valid value.\n', 8396) The first row is updated fine. However, for all subsequent rows the driver seems to loose track of the fact that the parameter to .execute() is a list (or a tuple). I believe that mxodbc's inability to update a Sybase 15 smallint or int with a null (using None) was present in the previous release of mxodbc. However, the inability to update successive rows of a table using .execute() (with BIND_USING_SQLTYPE) seems to be new with mxodbc 3.1. Any ideas? Thanks for the help. -dale On 12/23/2010 11:58 PM, Dale Arntson wrote: > The syntax error is my fault. I was trying to pare down some real code. > Here is a test example that illustrates the problem, two problems really. > > I want to update this table: > > CREATE TABLE friend ( > name varchar(20) NOT NULL, > age smallint NULL, > birthdate datetime NULL, > favorite_beer varchar(20) NULL > ) > > Using these rows: > > rows = [[28, '06/09/1982', None, 'Stephanie'], > [60, None, 'Corona', 'Raphael'], > [None, '09/23/1960', 'Pilsner', 'Johanna']] > > With this function: > > def load_data(m): > sql = "Update friend set age = ?, birthdate = ?, " \ > "favorite_beer = ? where name = ?" > for r in rows: > print "Updating %s" % r[3] > m.db.cur.executedirect(sql,r) > m.db.con.commit() > > Using the above, I get the following output: > > >>> load_data(m) > Updating Stephanie > Updating Raphael > Updating Johanna > Traceback (most recent call last): > File "", line 1, in > File "c:\dale\dev\gbs\test\code\grin\python-49A3Dj.py", line 84, in > load_data > mx.ODBC.Error.ProgrammingError: ('42000', 257, "[Sybase][ODBC > Driver][Adaptive Server Enterprise]Implicit conversion from datatype > 'CHAR' to 'SMALLINT' is not allowed. Use the CONVERT function to run > this query.\n", 8396) > > The odbc driver thinks that age = None is a char. I get the same output > using: > > BIND_USING_PYTHONTYPE and .executedirect() > BIND_USING_PYTHONTYPE and .execute() > BIND_USING_SQLTYPE and .executedirect() > > However, if I use: > > BIND_USING_SQLTYPE and .execute() > > I get this output. The code processes the first row fine, then seems to > barf on trying to use the cached sql the second time around. > > >>> load_data(m) > Updating Stephanie > Updating Raphael > Traceback (most recent call last): > File "", line 1, in > File "c:\dale\dev\gbs\test\code\grin\python-49AEcR.py", line 84, in > load_data > mx.ODBC.Error.ProgrammingError: ('ZZZZZ', 3814, '[Sybase][ODBC > Driver][Adaptive Server Enterprise]The parameter of type 61 did not have > a valid value.\n', 8396) > > I hope this example is a little clearer. > > -dale > > > > On 12/23/2010 2:20 PM, M.-A. Lemburg wrote: >> Dale Arntson wrote: >>> Hi All, >>> >>> If I execute the following function using mxodbc 3.1 against a Sybase >>> 15.5 database, >>> >>> def load_data(m): >>> count = 0 >>> sql = "update uc_gbs_pick_list2 " \ >>> "set state = ?, viewability = ?, conditions = ?, \ >>> "where barcode = ?" >> >> Shouldn't the above read: >> >> sql = ("update uc_gbs_pick_list2 " >> "set state = ?, viewability = ?, conditions = ? " >> "where barcode = ?") >> >> ? >> >> I get a SyntaxError for your version. >> >>> for r in m.rows: >>> m.db.cur.execute(sql,r) >>> count += 1 >>> if count % 10000 == 0: m.db.con.commit() >>> m.db.con.commit() >>> >>> I get this error: >>> >>> Traceback (most recent call last): >>> File "c:\dale\dev\gbs\test\code\grin\python-49AQec.py", line 48, in main >>> File "c:\dale\dev\gbs\test\code\grin\python-49AQec.py", line 166, in >>> load_data >>> InterfaceError: ('HY010', 30102, '[Sybase][ODBC Driver]Function sequence >>> error', 8148) >>> >>> It updates the first row correctly, but throws an error on the second >>> row. If I use: .executedirect instead of .execute in the above code, I >>> get the following error on the first row: >>> >>> Traceback (most recent call last): >>> File "c:\dale\dev\gbs\test\code\grin\python-49Adoi.py", line 48, in main >>> File "c:\dale\dev\gbs\test\code\grin\python-49Adoi.py", line 166, in >>> load_data >>> ProgrammingError: ('42000', 257, "[Sybase][ODBC Driver][Adaptive Server >>> Enterprise]Implicit conversion from datatype 'CHAR' to 'SMALLINT' is not >>> allowed. Use the CONVERT function to run this query.\n", 8396) >>> >>> With .executedirect, but not with .execute, Sybase thinks that a None >>> value in python used in an sql smallint column is a char, and will not >>> save it as a sql NULL. This is the case whether or not I use the >>> following with .executedirect: >>> >>> m.db.con.bindmethod = mx.ODBC.Windows.BIND_USING_SQLTYPE or >>> m.db.con.bindmethod = mx.ODBC.Windows.BIND_USING_PYTHONTYPE >>> >>> Any ideas or workarounds? >> >> Please try the above corrected sql line. Note that I have removed >> the trailing comman after the last set part as well. >> >> If you still get the errors you mentioned, please provide a data >> extract as well. Otherwise, it's difficult to tell what is >> getting converted and how. >> >> Normally, .executedirect() will pass the SQL and data verbatim >> to the server and let it do the binding. The operation then >> always maps to a Python type binding. With .execute(), the binding >> happens on the client side, based on the type information the client >> received from the server. >> >> With some drivers, .executedirect() will also bind on the client >> side, but then use the Python types as basis for the binding >> and pass the resulting SQL string to the server for execution. >> >> This is why you sometimes see different behavior with .executedirect() >> and .execute(). >> > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Tue Jan 4 22:54:54 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 4 22:54:58 2011 Subject: [egenix-users] Problem with mxodbc 3.1 and Sybase 15.5 In-Reply-To: <4D226642.80603@uchicago.edu> References: slrnhvksl1.r36.aclark@aclark.aclark.net <4D13ABBD.8020705@uchicago.edu> <4D13AF01.7000003@egenix.com> <4D143673.6000609@uchicago.edu> <4D226642.80603@uchicago.edu> Message-ID: <4D23972E.5020608@egenix.com> Hi Dale, could you try enabling the ODBC tracing function in the Windows ODBC manager and send us the ODBC log ? Here's the documentation on how to enable tracing in the MS ODBC Manager: http://support.microsoft.com/kb/274551 If standard tracing doesn't work, you could try the Visual Studio Analyzer: http://msdn.microsoft.com/en-us/library/aa234848.aspx Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 04 2011) >>> 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 our new mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/ Dale Arntson wrote: > Hi All, > > I haven't heard back from anyone yet, so I thought I would give any > Sybase 15 users out there some code that would make it easier to > replicate my problem by cutting and pasting. Just replace the 'xxx's > with the proper dsn info. > > For this demo, I am using a Sybase ASE ODBC driver (version 15.00.00.50, > 32 bit) on Windows XP against a Sybase 15.5 ASE database. > > > import mx.ODBC.Windows > import traceback > > > class db_class: > def __init__(self): > datasource = 'xxx' > user = 'xxx' > password = 'xxx' > self.dsn = "dsn=%s;uid=%s;pwd=%s" % (datasource, user, password) > self.con = None > self.cur = None > > def open(self): > self.con = mx.ODBC.Windows.DriverConnect(self.dsn) > self.con.bindmethod = mx.ODBC.Windows.BIND_USING_SQLTYPE > self.cur = self.con.cursor() > self.cur.executedirect("set chained off") > > def close(self): > self.con.commit() > self.cur.close() > self.con.close() > > > def create_table(db): > db.cur.tables(table='friend') > if db.cur.fetchone(): > db.cur.executedirect('drop table friend') > sql = "create table friend ( " \ > "name varchar(20) not null, " \ > "age smallint null, " \ > "birthdate datetime null, " \ > "favorite_beer varchar(20) null)" > db.cur.executedirect(sql) > > > def insert_data(db): > rows = [['Stephanie', 28, '06/09/1982', 'Budwiser'], > ['Raphael', 60, '01/16/50', 'Corona'], > ['Johanna', 50, '09/23/1960', 'Pilsner']] > sql = "insert into friend values (?,?,?,?)" > for r in rows: > print "Inserting %s" % r[0] > db.cur.executedirect(sql,r) > db.con.commit() > > > def update_data(db): > rows = [[28, '06/09/1982', None, 'Stephanie'], > [60, None, 'Corona', 'Raphael'], > [None, '09/23/1960', 'Pilsner', 'Johanna']] > sql = "Update friend set age = ?, birthdate = ?, " \ > "favorite_beer = ? where name = ?" > for r in rows: > print "Updating %s" % r[3] > db.cur.executedirect(sql,r) > db.con.commit() > > > Now, using the above code, as expected, I can do the following: > >>>> db = db_class() >>>> db.open() >>>> create_table(db) >>>> insert_data(db) > Inserting Stephanie > Inserting Raphael > Inserting Johanna > > However, when I try to update my table by nullifying some of the > columns, I get an error. I can nullify a varchar, and a datetime column > just fine. But, when I try to nullify a smallint column, I get an error: > >>>> update_data(db) > Updating Stephanie > Updating Raphael > Updating Johanna > Traceback (most recent call last): > File "", line 1, in > File "c:\dale\dev\gbs\test\code\grin\python-49AGef.py", line 57, in > update_data > mx.ODBC.Error.ProgrammingError: ('42000', 257, "[Sybase][ODBC > Driver][Adaptive Server Enterprise]Implicit conversion from datatype > 'CHAR' to 'SMALLINT' is not allowed. Use the CONVERT function to run > this query.\n", 8396) > > The Sybase odbc driver seems to think that age = None is a char, when, > of course, it should be a null. > > I get this error using the following cursor.execute*() methods and > connection.bindmethod values: > > .executedirect() and BIND_USING_SQLTYPE (as in the above code) > .executedirect() and BIND_USING_PYTHONTYPE > .execute() and BIND_USING_PYTHONTYPE > > However, when I change the above code to use: > > .execute() and BIND_USING_SQLTYPE > > to do the update, I get a different error: > >>>> update_data(db) > Updating Stephanie > Updating Raphael > Traceback (most recent call last): > File "", line 1, in > File "c:\dale\dev\gbs\test\code\grin\python-49ATol.py", line 57, in > update_data > mx.ODBC.Error.ProgrammingError: ('ZZZZZ', 3814, '[Sybase][ODBC > Driver][Adaptive Server Enterprise]The parameter of type 61 did not have > a valid value.\n', 8396) > > The first row is updated fine. However, for all subsequent rows the > driver seems to loose track of the fact that the parameter to .execute() > is a list (or a tuple). > > I believe that mxodbc's inability to update a Sybase 15 smallint or int > with a null (using None) was present in the previous release of mxodbc. > However, the inability to update successive rows of a table using > .execute() (with BIND_USING_SQLTYPE) seems to be new with mxodbc 3.1. > > Any ideas? Thanks for the help. > > -dale > > > On 12/23/2010 11:58 PM, Dale Arntson wrote: >> The syntax error is my fault. I was trying to pare down some real code. >> Here is a test example that illustrates the problem, two problems really. >> >> I want to update this table: >> >> CREATE TABLE friend ( >> name varchar(20) NOT NULL, >> age smallint NULL, >> birthdate datetime NULL, >> favorite_beer varchar(20) NULL >> ) >> >> Using these rows: >> >> rows = [[28, '06/09/1982', None, 'Stephanie'], >> [60, None, 'Corona', 'Raphael'], >> [None, '09/23/1960', 'Pilsner', 'Johanna']] >> >> With this function: >> >> def load_data(m): >> sql = "Update friend set age = ?, birthdate = ?, " \ >> "favorite_beer = ? where name = ?" >> for r in rows: >> print "Updating %s" % r[3] >> m.db.cur.executedirect(sql,r) >> m.db.con.commit() >> >> Using the above, I get the following output: >> >> >>> load_data(m) >> Updating Stephanie >> Updating Raphael >> Updating Johanna >> Traceback (most recent call last): >> File "", line 1, in >> File "c:\dale\dev\gbs\test\code\grin\python-49A3Dj.py", line 84, in >> load_data >> mx.ODBC.Error.ProgrammingError: ('42000', 257, "[Sybase][ODBC >> Driver][Adaptive Server Enterprise]Implicit conversion from datatype >> 'CHAR' to 'SMALLINT' is not allowed. Use the CONVERT function to run >> this query.\n", 8396) >> >> The odbc driver thinks that age = None is a char. I get the same output >> using: >> >> BIND_USING_PYTHONTYPE and .executedirect() >> BIND_USING_PYTHONTYPE and .execute() >> BIND_USING_SQLTYPE and .executedirect() >> >> However, if I use: >> >> BIND_USING_SQLTYPE and .execute() >> >> I get this output. The code processes the first row fine, then seems to >> barf on trying to use the cached sql the second time around. >> >> >>> load_data(m) >> Updating Stephanie >> Updating Raphael >> Traceback (most recent call last): >> File "", line 1, in >> File "c:\dale\dev\gbs\test\code\grin\python-49AEcR.py", line 84, in >> load_data >> mx.ODBC.Error.ProgrammingError: ('ZZZZZ', 3814, '[Sybase][ODBC >> Driver][Adaptive Server Enterprise]The parameter of type 61 did not have >> a valid value.\n', 8396) >> >> I hope this example is a little clearer. >> >> -dale >> >> >> >> On 12/23/2010 2:20 PM, M.-A. Lemburg wrote: >>> Dale Arntson wrote: >>>> Hi All, >>>> >>>> If I execute the following function using mxodbc 3.1 against a Sybase >>>> 15.5 database, >>>> >>>> def load_data(m): >>>> count = 0 >>>> sql = "update uc_gbs_pick_list2 " \ >>>> "set state = ?, viewability = ?, conditions = ?, \ >>>> "where barcode = ?" >>> >>> Shouldn't the above read: >>> >>> sql = ("update uc_gbs_pick_list2 " >>> "set state = ?, viewability = ?, conditions = ? " >>> "where barcode = ?") >>> >>> ? >>> >>> I get a SyntaxError for your version. >>> >>>> for r in m.rows: >>>> m.db.cur.execute(sql,r) >>>> count += 1 >>>> if count % 10000 == 0: m.db.con.commit() >>>> m.db.con.commit() >>>> >>>> I get this error: >>>> >>>> Traceback (most recent call last): >>>> File "c:\dale\dev\gbs\test\code\grin\python-49AQec.py", line 48, in >>>> main >>>> File "c:\dale\dev\gbs\test\code\grin\python-49AQec.py", line 166, in >>>> load_data >>>> InterfaceError: ('HY010', 30102, '[Sybase][ODBC Driver]Function >>>> sequence >>>> error', 8148) >>>> >>>> It updates the first row correctly, but throws an error on the second >>>> row. If I use: .executedirect instead of .execute in the above code, I >>>> get the following error on the first row: >>>> >>>> Traceback (most recent call last): >>>> File "c:\dale\dev\gbs\test\code\grin\python-49Adoi.py", line 48, in >>>> main >>>> File "c:\dale\dev\gbs\test\code\grin\python-49Adoi.py", line 166, in >>>> load_data >>>> ProgrammingError: ('42000', 257, "[Sybase][ODBC Driver][Adaptive Server >>>> Enterprise]Implicit conversion from datatype 'CHAR' to 'SMALLINT' is >>>> not >>>> allowed. Use the CONVERT function to run this query.\n", 8396) >>>> >>>> With .executedirect, but not with .execute, Sybase thinks that a None >>>> value in python used in an sql smallint column is a char, and will not >>>> save it as a sql NULL. This is the case whether or not I use the >>>> following with .executedirect: >>>> >>>> m.db.con.bindmethod = mx.ODBC.Windows.BIND_USING_SQLTYPE or >>>> m.db.con.bindmethod = mx.ODBC.Windows.BIND_USING_PYTHONTYPE >>>> >>>> Any ideas or workarounds? >>> >>> Please try the above corrected sql line. Note that I have removed >>> the trailing comman after the last set part as well. >>> >>> If you still get the errors you mentioned, please provide a data >>> extract as well. Otherwise, it's difficult to tell what is >>> getting converted and how. >>> >>> Normally, .executedirect() will pass the SQL and data verbatim >>> to the server and let it do the binding. The operation then >>> always maps to a Python type binding. With .execute(), the binding >>> happens on the client side, based on the type information the client >>> received from the server. >>> >>> With some drivers, .executedirect() will also bind on the client >>> side, but then use the Python types as basis for the binding >>> and pass the resulting SQL string to the server for execution. >>> >>> This is why you sometimes see different behavior with .executedirect() >>> and .execute(). >>> >> >> >> _______________________________________________________________________ >> eGenix.com User Mailing List http://www.egenix.com/ >> https://www.egenix.com/mailman/listinfo/egenix-users > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > https://www.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Wed Jan 5 01:05:30 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 5 01:05:34 2011 Subject: [egenix-users] Problem with mxodbc 3.1 and Sybase 15.5 In-Reply-To: <4D23AB65.1010604@uchicago.edu> References: slrnhvksl1.r36.aclark@aclark.aclark.net <4D13ABBD.8020705@uchicago.edu> <4D13AF01.7000003@egenix.com> <4D143673.6000609@uchicago.edu> <4D226642.80603@uchicago.edu> <4D23972E.5020608@egenix.com> <4D23AB65.1010604@uchicago.edu> Message-ID: <4D23B5CA.2010607@egenix.com> Dale Arntson wrote: > The odbc trace log is attached. Thanks. It appears that the Sybase ODBC driver doesn't like the fact that mxODBC always binds None (NULL) values using SQL_CHAR - since the data type doesn't matter when passing in NULL values. This is in line with the ODBC standard and works well with all other ODBC drivers being used with mxODBC. No idea why the error message says "Implicit conversion from datatype 'CHAR' to 'SMALLINT' is not allowed.". We already have a whole set of work-arounds for the Sybase driver in mxODBC, so I suppose we'll have to find yet another one for this particular quirk of the driver... Regarding the other error message "The parameter of type 61 did not have a valid value." I can't really say what's wrong here, since ODBC doesn't have a type code 61 and the log doesn't show such a code being used either. > Thanks, > > -dale > > On 1/4/2011 3:54 PM, M.-A. Lemburg wrote: >> Hi Dale, >> >> could you try enabling the ODBC tracing function in the Windows >> ODBC manager and send us the ODBC log ? >> >> Here's the documentation on how to enable tracing in the >> MS ODBC Manager: >> >> http://support.microsoft.com/kb/274551 >> >> If standard tracing doesn't work, you could try the >> Visual Studio Analyzer: >> >> http://msdn.microsoft.com/en-us/library/aa234848.aspx >> >> Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 05 2011) >>> 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 our new mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/ From d-arntson at uchicago.edu Wed Jan 5 13:48:30 2011 From: d-arntson at uchicago.edu (Dale Arntson) Date: Wed Jan 5 20:48:36 2011 Subject: [egenix-users] Problem with mxodbc 3.1 and Sybase 15.5 In-Reply-To: <4D23B5CA.2010607@egenix.com> References: slrnhvksl1.r36.aclark@aclark.aclark.net <4D13ABBD.8020705@uchicago.edu> <4D13AF01.7000003@egenix.com> <4D143673.6000609@uchicago.edu> <4D226642.80603@uchicago.edu> <4D23972E.5020608@egenix.com> <4D23AB65.1010604@uchicago.edu> <4D23B5CA.2010607@egenix.com> Message-ID: <4D24CB0E.6060402@uchicago.edu> Thanks for looking into it. I suspected that their driver was non-conforming. Sybase had previously used drivers by DataDirect in their products, and decided to drop them and to write their own instead. The 61 error would be a major stumbling block, except that it only seems to occur when iterating with .execute(). Since .executedirect() does not exhibit this behavior, I have a work around. -dale On 1/4/2011 6:05 PM, M.-A. Lemburg wrote: > Dale Arntson wrote: >> The odbc trace log is attached. > > Thanks. It appears that the Sybase ODBC driver doesn't like the > fact that mxODBC always binds None (NULL) values using SQL_CHAR - > since the data type doesn't matter when passing in NULL values. > This is in line with the ODBC standard and works well with > all other ODBC drivers being used with mxODBC. > > No idea why the error message says "Implicit conversion from datatype 'CHAR' to 'SMALLINT' is not > allowed.". > > We already have a whole set of work-arounds for the Sybase > driver in mxODBC, so I suppose we'll have to find yet another > one for this particular quirk of the driver... > > Regarding the other error message "The parameter of type 61 did not have a valid value." > I can't really say what's wrong here, since ODBC doesn't have a > type code 61 and the log doesn't show such a code being used either. > >> Thanks, >> >> -dale >> >> On 1/4/2011 3:54 PM, M.-A. Lemburg wrote: >>> Hi Dale, >>> >>> could you try enabling the ODBC tracing function in the Windows >>> ODBC manager and send us the ODBC log ? >>> >>> Here's the documentation on how to enable tracing in the >>> MS ODBC Manager: >>> >>> http://support.microsoft.com/kb/274551 >>> >>> If standard tracing doesn't work, you could try the >>> Visual Studio Analyzer: >>> >>> http://msdn.microsoft.com/en-us/library/aa234848.aspx >>> >>> Thanks, > From kingsley.turner at openfieldcommunications.com Thu Jan 13 09:15:51 2011 From: kingsley.turner at openfieldcommunications.com (Kingsley Turner) Date: Wed Jan 12 23:16:28 2011 Subject: [egenix-users] mxDateTime on pyPgSQL/PostgreSQL applies timezone? Message-ID: <4D2E2817.2030901@openfieldcommunications.com> Hi, I'm confused as to what's going on with a PostgreSQL "timestamp" type converted back to string. Selecting my timestamp field from PostgreSQL via psql gives: 2011-01-12 21:54:11 Yet in my code, when I str() or mx.DateTime.ISO.strUTC() the mx.DateTime representation of the field returned by pyPgSQL, I get 2011-01-13 08:01:04.00 2011-01-13 08:54:11+0000 I'm currently in UTC+11 (10+summer) Any suggestions as to what might be happening here? When I first connect to PostgreSQL, I always SET TIMEZONE UTC. cheers, -Kingsley -------------- next part -------------- An HTML attachment was scrubbed... URL: /mailman-archives/egenix-users/attachments/20110113/06f775df/attachment.htm From mal at egenix.com Thu Jan 13 10:04:38 2011 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 13 10:04:41 2011 Subject: [egenix-users] mxDateTime on pyPgSQL/PostgreSQL applies timezone? In-Reply-To: <4D2E2817.2030901@openfieldcommunications.com> References: <4D2E2817.2030901@openfieldcommunications.com> Message-ID: <4D2EC026.4020709@egenix.com> Kingsley Turner wrote: > Hi, > > I'm confused as to what's going on with a PostgreSQL "timestamp" type > converted back to string. > > Selecting my timestamp field from PostgreSQL via psql gives: > > 2011-01-12 21:54:11 > > > Yet in my code, when I str() or mx.DateTime.ISO.strUTC() the mx.DateTime > representation of the field returned by pyPgSQL, I get > > 2011-01-13 08:01:04.00 > 2011-01-13 08:54:11+0000 > > > I'm currently in UTC+11 (10+summer) > > Any suggestions as to what might be happening here? > > When I first connect to PostgreSQL, I always SET TIMEZONE UTC. mxDateTime stores the date/time value depending on what you pass to the constructor. It does not manipulate the value, but does apply timezone conversions in case you tell it to convert the time to UTC. You would have to track down how PyPgSQL creates the mxDateTime instances to tell whether the wrong constructor is being used or whether PyPgSQL itself converts the stored UTC time value to local time. I am a bit confused about the two examples you gave, since they should not differ in the minute and seconds values. The first appears to point to a different database row. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 13 2011) >>> 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 our new mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/ From kingsley.turner at openfieldcommunications.com Fri Jan 14 05:28:48 2011 From: kingsley.turner at openfieldcommunications.com (Kingsley Turner) Date: Thu Jan 13 19:29:28 2011 Subject: [egenix-users] mxDateTime on pyPgSQL/PostgreSQL applies timezone? In-Reply-To: <4D2EC026.4020709@egenix.com> References: <4D2E2817.2030901@openfieldcommunications.com> <4D2EC026.4020709@egenix.com> Message-ID: <4D2F4460.8070406@openfieldcommunications.com> On 13/01/11 20:04, M.-A. Lemburg wrote: > I'm confused as to what's going on with a PostgreSQL "timestamp" type >> converted back to string. >> >> Selecting my timestamp field from PostgreSQL via psql gives: >> >> 2011-01-12 21:54:11 >> >> >> Yet in my code, when I str() or mx.DateTime.ISO.strUTC() the mx.DateTime >> representation of the field returned by pyPgSQL, I get >> >> 2011-01-13 08:01:04.00 >> 2011-01-13 08:01:04+0000 >> >> >> I'm currently in UTC+11 (10+summer) >> >> Any suggestions as to what might be happening here? >> >> When I first connect to PostgreSQL, I always SET TIMEZONE UTC. > mxDateTime stores the date/time value depending on what you > pass to the constructor. It does not manipulate the value, > but does apply timezone conversions in case you tell it to > convert the time to UTC. > > You would have to track down how PyPgSQL creates the mxDateTime > instances to tell whether the wrong constructor is being used > or whether PyPgSQL itself converts the stored UTC time value > to local time. > > I am a bit confused about the two examples you gave, since > they should not differ in the minute and seconds values. > The first appears to point to a different database row. Thanks for that. I admit my example is not very good, the two times should be the same as far as minutes go, but with the hours incorrect. I've corrected it above ;) The big problem was that it was ~ 10 hours out. I'm in the process of trying another PostgreSQL module, both pyGreSQL or pyscopg so far. cheers, -Kingsley From charlie at egenix.com Thu Jan 13 19:39:34 2011 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 13 19:39:39 2011 Subject: [egenix-users] mxDateTime on pyPgSQL/PostgreSQL applies timezone? In-Reply-To: <4D2F4460.8070406@openfieldcommunications.com> References: <4D2E2817.2030901@openfieldcommunications.com> <4D2EC026.4020709@egenix.com> <4D2F4460.8070406@openfieldcommunications.com> Message-ID: Am 13.01.2011, 19:28 Uhr, schrieb Kingsley Turner : > I'm in the process of trying another PostgreSQL module, both pyGreSQL or > pyscopg so far. Well, apart from using mxODBC with an ODBC driver ;-) there is also pg8000. pyPgSQL is not considered to be well-maintained. Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source >>> 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 our new mxODBC.Connect Python Database Interface 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 http://www.egenix.com/company/contact/