From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 11:13:22 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 15:13:54 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 15:21:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 15:21:17 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 16:00:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 20:01:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 13 20:01:41 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 13 20:01:42 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 08:02:22 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 12:00:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 12:00:47 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 12:00:48 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 16:00:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 16:00:46 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 20:00:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 14 20:00:44 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 14 20:00:45 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 08:02:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 08:02:09 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 12:00:53 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 16:00:45 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 15 20:00:45 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 08:02:32 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 08:02:33 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 12:00:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 16:00:49 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 16:00:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 16 20:00:45 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 08:02:35 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 12:01:03 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 16:00:51 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:52 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 17 20:00:53 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 08:04:19 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 12:01:06 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 16:01:31 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 18 20:00:57 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 08:04:40 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 08:04:41 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 12:01:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 16:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 19 16:03:00 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 16:03:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 19 20:00:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 08:07:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:07:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 08:07:06 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 12:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 20 12:02:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 12:02:06 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 16:00:54 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 16:00:55 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 20 20:00:49 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 08:03:55 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 12:01:03 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 12:01:04 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 16:00:52 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 16:00:53 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 20:00:51 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 20:00:52 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 21 20:00:52 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 08:02:47 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 12:00:52 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 12:00:53 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:22 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 16:01:23 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 20:01:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 20:01:18 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 22 20:01:18 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 22 20:01:18 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 20:01:18 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 20:01:18 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 22 20:01:18 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 08:02:43 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 12:00:58 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 16:01:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 20:00:53 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 23 20:00:54 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 23 20:00:54 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 20:00:54 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 20:00:54 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 23 20:00:54 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 08:03:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 24 08:03:15 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 08:03:16 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 12:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 24 12:03:00 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:03:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:03:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 12:03:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 16:01:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 16:01:25 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 24 20:01:57 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 08:02:05 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 12:01:03 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 25 16:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 16:01:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Jan 25 20:00:55 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 08:05:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 26 08:05:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 08:05:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 12:01:07 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 16:00:55 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Jan 26 20:00:48 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 08:06:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 08:06:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 08:06:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 08:06:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 08:06:47 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 08:06:47 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 08:06:47 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 08:06:47 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 12:02:12 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 16:01:08 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Jan 27 20:00:57 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 08:05:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 08:05:44 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 08:05:44 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 08:05:44 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 08:05:44 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 12:01:56 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 16:00:58 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Jan 28 20:00:58 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:34 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 08:07:35 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 12:01:01 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 12:01:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 12:01:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 12:01:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 12:01:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 16:00:55 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 20:00:56 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 20:00:58 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Jan 29 20:00:58 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 08:08:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 08:08:56 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 08:08:57 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 08:08:57 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 08:08:57 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 08:08:57 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 12:03:57 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 16:04:15 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Jan 30 20:02:16 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 08:07:54 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 08:07:55 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 12:04:18 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 12:04:19 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 16:02:21 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Jan 31 20:01:10 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 08:09:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 1 08:09:47 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:48 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 08:09:49 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 12:02:45 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 16:01:09 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 1 20:01:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 08:12:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:47 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 08:12:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 08:12:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 12:02:51 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 12:02:52 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 16:01:14 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 2 20:01:03 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 08:12:19 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 3 08:12:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 08:12:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 08:12:22 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 08:12:23 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 12:02:42 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:04 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 16:01:05 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 3 20:01:10 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 08:08:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 4 08:08:03 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:08:03 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 08:08:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 08:08:06 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 4 12:02:44 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 12:02:46 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 16:01:14 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 4 20:01:06 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 4 20:01:07 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:58 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 08:07:59 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 12:02:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 12:02:46 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 16:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 5 16:01:10 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 16:01:11 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 5 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 5 20:01:01 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 08:15:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:15:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 08:15:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 08:15:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:15:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 08:15:23 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 08:15:23 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 08:15:23 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 08:15:23 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 08:15:24 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 08:15:24 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 08:15:24 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 08:15:24 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 12:02:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 12:02:46 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 12:02:46 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 12:02:46 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 12:02:46 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 12:02:46 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 16:01:09 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 6 20:01:01 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 6 20:01:02 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 08:23:39 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 7 08:23:44 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:23:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:23:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 08:23:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:45 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:23:45 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 08:23:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 08:23:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:23:46 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 08:23:46 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 08:23:47 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 12:03:20 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 12:03:21 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 12:03:21 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 12:03:21 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 12:03:21 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 7 16:01:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 16:01:12 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 7 20:01:07 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:07 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 7 20:01:08 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 08:22:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 08:22:44 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 08:22:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 08:22:45 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 08:22:45 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 08:22:45 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 08:22:45 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 08:22:46 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 12:03:24 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 16:01:16 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 8 20:01:06 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 8 20:01:07 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 08:09:21 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 9 08:09:22 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:22 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 08:09:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:23 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 08:09:25 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 12:03:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 12:03:17 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 16:01:17 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 9 20:01:12 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 08:20:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 10 08:20:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:20:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:20:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:20:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:20:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 08:20:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:20:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 08:20:12 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 08:20:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 08:20:13 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 08:20:13 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 08:20:13 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 08:20:13 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 08:20:13 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 08:20:13 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 12:03:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 10 12:03:40 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 12:03:41 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 16:01:12 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 20:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Feb 10 20:01:15 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:15 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Feb 10 20:01:16 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 08:12:55 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:56 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 08:12:57 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 12:02:41 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 16:01:08 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 20:00:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sat Feb 11 20:01:00 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 08:09:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 12 08:09:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 08:09:26 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 12:02:49 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 12:02:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 12:02:50 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 12:02:50 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 12:02:50 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 12:02:50 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 12:02:50 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:12 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 16:01:13 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Sun Feb 12 20:01:06 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 08:17:05 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 13 08:17:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:17:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:17:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:17:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:17:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 08:17:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 08:17:09 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 12:03:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 13 12:03:08 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 12:03:10 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 16:01:29 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 20:01:08 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Mon Feb 13 20:01:09 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 08:19:23 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 08:19:26 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 08:19:26 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:26 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 08:19:27 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 12:03:25 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 16:01:33 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Tue Feb 14 20:01:14 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 08:27:53 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 15 08:27:57 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:27:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:57 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:27:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 08:27:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:59 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:27:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:27:59 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 08:28:00 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 08:28:01 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 08:28:01 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 08:28:01 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 08:28:01 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 12:05:30 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 12:05:31 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 16:01:36 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:10 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 19:28:11 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 20:13:40 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 20:13:41 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 20:13:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Wed Feb 15 20:13:42 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Wed Feb 15 20:13:42 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 20:13:42 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 20:13:42 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Wed Feb 15 20:13:42 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 16 08:46:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Thu Feb 16 08:46:24 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:24 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Thu Feb 16 08:46:25 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Thu Feb 16 08:46:26 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd. From Charles.F.Bearden at uth.tmc.edu Fri Mar 5 12:29:07 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Mar 31 16:33:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: I'm using mx.ODBC version 2.0.1 (that's the version in site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I am having a puzzling right truncation problem when trying to insert even small values into a table. In order to isolate variables, I am inserting values into only required (non-NULL) fields. INSERTing the same values into the table works via Query Analyzer. Here is sample code, traceback, & the table definition. Any ideas on how to make this work would be greatly appreciated--thanks in advance! --------------------------begin snippet----------------------------- import time from mx.ODBC.Windows import DriverConnect import mx.DateTime con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") cur = con.cursor() datestmp = mx.DateTime.localtime(time.time()) val_t = (10073787, 0, datestmp, 1) ins_stmnt = ''' INSERT INTO pmLinkHistory ('PMID', 'Ord', 'LastActionDate', 'LastAction') VALUES (?, ?, ?, ?) ''' cur.execute(ins_stmnt, val_t) con.close() -------------------------begin traceback---------------------------- Traceback (most recent call last): File "./simpletest.py", line 18, in ? cur.execute(ins_stmnt, val_t) mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String data, right truncation', 4579) -------------------------begin table def---------------------------- CREATE TABLE [dbo].[pmLinkHistory] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [PMID] [int] NOT NULL , [Ord] [smallint] NOT NULL , [LastActionDate] [datetime] NOT NULL , [LastAction] [smallint] NOT NULL , [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS NULL , [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS NULL ) ON [PRIMARY] --------------------------end table def----------------------------- (The table also has a normal primary key comprising PMID and Ord. No other indices, triggers, or stored procedures.) Chuck Bearden Systems Analyst III School of Health Information Sciences University of Texas at Houston 713.500.3954 (voice) 713.500.3907 (fax) Charles.F.Bearden@uth.tmc.edu From Joseph.Kocherhans at hsc.utah.edu Mon Mar 8 11:57:40 2004 From: Joseph.Kocherhans at hsc.utah.edu (Joseph Kocherhans) Date: Fri Mar 31 16:33:42 2006 Subject: [egenix-users] ZopeDA columninfos() Problems Message-ID: I'm developing a zope product, and when I try to call the columninfos() method on a connection object I get the following traceback: Traceback (most recent call last): File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 100, in publish request, bind=1) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", line 88, in mapply if debug is not None: return debug(object,args,context) File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", line 40, in call_object result=apply(object,args) # Type s to step into published object. File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", line 28, in getColumns File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos NameError: global name 'self' is not defined I'm doing something like conn = mymxZodbcConnection.get_connection() return conn.columninfos() I'm not sure where to start here since I can't see the source code ;) Thanks, Joseph From mal at egenix.com Thu Mar 11 11:29:41 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40503F95.2050502@egenix.com> Charles Bearden wrote: > I'm using mx.ODBC version 2.0.1 (that's the version in > site-packages\mx\ODBC\ODBC.py; the "commercial" download file is version > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS SQL Server. I > am having a puzzling right truncation problem when trying to insert even > small values into a table. In order to isolate variables, I am > inserting values into only required (non-NULL) fields. INSERTing the > same values into the table works via Query Analyzer. Here is sample > code, traceback, & the table definition. Any ideas on how to make this > work would be greatly appreciated--thanks in advance! > > --------------------------begin snippet----------------------------- > import time > from mx.ODBC.Windows import DriverConnect > import mx.DateTime > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > cur = con.cursor() > > datestmp = mx.DateTime.localtime(time.time()) Try to use a string here: '2004-03-11 10:00:00' and see whether that makes any difference (the ODBC driver could be having trouble with the seconds fraction - even though we've never heard of such problems with SQL Server before). > val_t = (10073787, 0, datestmp, 1) > > ins_stmnt = ''' > INSERT INTO pmLinkHistory > ('PMID', 'Ord', 'LastActionDate', 'LastAction') > VALUES > (?, ?, ?, ?) > ''' > cur.execute(ins_stmnt, val_t) > con.close() > > -------------------------begin traceback---------------------------- > > Traceback (most recent call last): > File "./simpletest.py", line 18, in ? > cur.execute(ins_stmnt, val_t) > mxODBC.Warning: ('22001', 0, '[Microsoft][ODBC SQL Server Driver]String > data, right truncation', 4579) > > -------------------------begin table def---------------------------- > > CREATE TABLE [dbo].[pmLinkHistory] ( > [ID] [int] IDENTITY (1, 1) NOT NULL , > [PMID] [int] NOT NULL , > [Ord] [smallint] NOT NULL , > [LastActionDate] [datetime] NOT NULL , > [LastAction] [smallint] NOT NULL , > [Info] [nvarchar] (24) COLLATE SQL_Latin1_General_CP1_CS_AS NULL > , > [Url] [nvarchar] (1024) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [LinkName] [nvarchar] (256) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Provider] [nvarchar] (128) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL , > [Notes] [nvarchar] (512) COLLATE SQL_Latin1_General_CP1_CS_AS > NULL > ) ON [PRIMARY] > > --------------------------end table def----------------------------- > (The table also has a normal primary key comprising PMID and Ord. No > other indices, triggers, or stored procedures.) > > > Chuck Bearden > Systems Analyst III > School of Health Information Sciences > University of Texas at Houston > 713.500.3954 (voice) > 713.500.3907 (fax) > Charles.F.Bearden@uth.tmc.edu > > > > _______________________________________________________________________ > eGenix.com User Mailing List http://www.egenix.com/ > http://lists.egenix.com/mailman/listinfo/egenix-users -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 08:06:15 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40503F95.2050502@egenix.com> Message-ID: [mal] > Charles Bearden wrote: > > I'm using mx.ODBC version 2.0.1 (that's the version in > > site-packages\mx\ODBC\ODBC.py; the "commercial" download > file is version > > 2.0.6) with ActivePython 2.3.2 Build 230 to talk to a MS > SQL Server. I > > am having a puzzling right truncation problem when trying > to insert even > > small values into a table. In order to isolate variables, I am > > inserting values into only required (non-NULL) fields. > INSERTing the > > same values into the table works via Query Analyzer. Here is sample > > code, traceback, & the table definition. Any ideas on how > to make this > > work would be greatly appreciated--thanks in advance! > > > > --------------------------begin snippet----------------------------- > > import time > > from mx.ODBC.Windows import DriverConnect > > import mx.DateTime > > > > con = DriverConnect("DSN=theDb;UID=theUser;PWD=thePwd") > > cur = con.cursor() > > > > datestmp = mx.DateTime.localtime(time.time()) > > Try to use a string here: '2004-03-11 10:00:00' and > see whether that makes any difference (the ODBC driver could > be having trouble with the seconds fraction - even though > we've never heard of such problems with SQL Server before). > I'm sorry, I thought this was well-known (and I also thought I had reported it earlier. Maybe I invented that last piece of knowledge :-). The driver does indeed have problems with fractional seconds in datetime values. Here's a little test program that demonstrates the problem, and a rather gash fix that I've used in my own code. I'm sure Marc-Andre can suggest a more elegant workaround until the driver is fixed. By the nature of things, one time in however many mx.DateTime.now() will return a value without a fractional part and both inserts will work without any problems. Murphy's law dictates that this usually happens when you want to demonstrate the error! # # mxdtdb.py: naff demonstration of datetime handling problem and workaround # import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys def doit(arg): print "Trying", arg try: curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) print "That seemed to work" except: print "Oops! We trod on the driver!" print traceback.format_exception_only(sys.exc_type, sys.exc_value) conn = db.DriverConnect("""Driver={SQL Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") curs = conn.cursor() curs.execute(""" CREATE TABLE TEST ( pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, dt DATETIME)""") now = dt.now() doit(now) doit(dt.DateTimeFromTicks(int(now))) # I could drop the table, but instead I just don't commit() Output from my last run is shown below: Trying 2004-03-11 07:57:03.88 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 07:57:03.00 That seemed to work regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From mal at egenix.com Thu Mar 11 14:48:35 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <40506E33.60808@egenix.com> Steve Holden wrote: > [mal] > >>>datestmp = mx.DateTime.localtime(time.time()) >> >>Try to use a string here: '2004-03-11 10:00:00' and >>see whether that makes any difference (the ODBC driver could >>be having trouble with the seconds fraction - even though >>we've never heard of such problems with SQL Server before). > > I'm sorry, I thought this was well-known (and I also thought I had > reported it earlier. Maybe I invented that last piece of knowledge :-). Probably just dropped off my horizon: looking at the list archives, you are right. I wonder whether this only affects certain versions of the MS ODBC driver ?! If so, please provide us with the information from connection.dbms_version connection.dbms_name connection.driver_name connection.driver_version We can then look into adding code to truncate the fraction in timestamps for MS SQL Server ODBC drivers. > The driver does indeed have problems with fractional seconds in datetime > values. Here's a little test program that demonstrates the problem, and > a rather gash fix that I've used in my own code. I'm sure Marc-Andre can > suggest a more elegant workaround until the driver is fixed. This should work: from mx import DateTime def msdate(datetime): int_second = int(datetime.second) if int_second != datetime.second: return DateTime.DateTime(datetime.year, datetime.month, datetime.day, datetime.hour, datetime.minute, int_second) else: return datetime > By the nature of things, one time in however many mx.DateTime.now() will > return a value without a fractional part and both inserts will work > without any problems. Murphy's law dictates that this usually happens > when you want to demonstrate the error! > > # > # mxdtdb.py: naff demonstration of datetime handling problem and > workaround > # > import mx.ODBC.Windows as db, mx.DateTime as dt, traceback, sys > > def doit(arg): > print "Trying", arg > try: > curs.execute("INSERT INTO TEST (dt) VALUES(?)", (arg,)) > print "That seemed to work" > except: > print "Oops! We trod on the driver!" > print traceback.format_exception_only(sys.exc_type, > sys.exc_value) > > conn = db.DriverConnect("""Driver={SQL > Server};Server=DellBoy;Database=PyCon;Uid=****;Pwd=****;""") > curs = conn.cursor() > > curs.execute(""" > CREATE TABLE TEST ( > pk INT IDENTITY(1, 1) NOT NULL PRIMARY KEY, > dt DATETIME)""") > > now = dt.now() > doit(now) > doit(dt.DateTimeFromTicks(int(now))) > > # I could drop the table, but instead I just don't commit() > > Output from my last run is shown below: > > Trying 2004-03-11 07:57:03.88 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 07:57:03.00 > That seemed to work > > regards > -- > Steve Holden http://www.holdenweb.com/ > ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ > Chairman, PyCON DC 2004 http://www.pycon.org/ > Telephone: +1-800 494 3119 Fax: +1 703 278 8289 > > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Thu Mar 11 10:39:35 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:42 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40506E33.60808@egenix.com> Message-ID: [mal] > Steve Holden wrote: > > [mal] > > > >>>datestmp = mx.DateTime.localtime(time.time()) > >> > >>Try to use a string here: '2004-03-11 10:00:00' and > >>see whether that makes any difference (the ODBC driver could > >>be having trouble with the seconds fraction - even though > >>we've never heard of such problems with SQL Server before). > > > > I'm sorry, I thought this was well-known (and I also thought I had > > reported it earlier. Maybe I invented that last piece of > knowledge :-). > > Probably just dropped off my horizon: looking at the list > archives, you are right. I wonder whether this only affects > certain versions of the MS ODBC driver ?! > Well, good to know I *didn't* invent the report! > If so, please provide us with the information from > > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version > Are these connection attributes a recent addition? My 2.0.5 doesn't have them, nor any reference to them in the documentation. Or have I misunderstood what I'm supposed to be reporting? Anyway, from the ODBC driver info applet: SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 Frankly I'm amazed that Windows Update hasn't provided me with something more recent. However, investigation reveals (amazingly) that I only have the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs ... 1 hour later ...] OK, now my driver is SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 but sadly this doesn't seem to be any better: Trying 2004-03-11 10:29:20.86 Oops! We trod on the driver! ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional truncation', 4579)\n"] Trying 2004-03-11 10:29:20.00 That seemed to work Maybe there's some option setting that will automatically truncate fractional seconds, and I don't have it set? Can't find anything in the documentation, though. FWIW, Transact-SQL docco says """Date and time data from January 1, 1753 through December 31, 9999, to an accuracy of one three-hundredth of a second (equivalent to 3.33 milliseconds or 0.00333 seconds). Values are rounded to increments of .000, .003, or .007 seconds, as shown in the table.""", so it should be capable of sub-second resolution. Perhaps it just doesn't like values that require rounding? > We can then look into adding code to truncate the fraction in > timestamps for MS SQL Server ODBC drivers. > Well OK, I hope this helps. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From Charles.F.Bearden at uth.tmc.edu Thu Mar 11 11:31:57 2004 From: Charles.F.Bearden at uth.tmc.edu (Charles Bearden) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows Message-ID: > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users- > bounces@lists.egenix.com] On Behalf Of Steve Holden > Sent: Thursday, March 11, 2004 9:40 AM > > [mal] > > Steve Holden wrote: > > > [mal] > > > > > >>>datestmp = mx.DateTime.localtime(time.time()) > > >> > > >>Try to use a string here: '2004-03-11 10:00:00' and > > >>see whether that makes any difference (the ODBC driver could > > >>be having trouble with the seconds fraction - even though > > >>we've never heard of such problems with SQL Server before). > > > > > > I'm sorry, I thought this was well-known (and I also thought I had > > > reported it earlier. Maybe I invented that last piece of > > knowledge :-). > > > > Probably just dropped off my horizon: looking at the list > > archives, you are right. I wonder whether this only affects > > certain versions of the MS ODBC driver ?! > > > Well, good to know I *didn't* invent the report! > > > If so, please provide us with the information from > > > > connection.dbms_version > > connection.dbms_name > > connection.driver_name > > connection.driver_version > > > Are these connection attributes a recent addition? My 2.0.5 doesn't have > them, nor any reference to them in the documentation. Or have I > misunderstood what I'm supposed to be reporting? > > Anyway, from the ODBC driver info applet: > > SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 > > Frankly I'm amazed that Windows Update hasn't provided me with something > more recent. However, investigation reveals (amazingly) that I only have > the hot fixes. [... upgrades to sp3a ... aagghh, I hate service packs > ... 1 hour later ...] OK, now my driver is > > SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 > > but sadly this doesn't seem to be any better: > > Trying 2004-03-11 10:29:20.86 > Oops! We trod on the driver! > ["Warning: ('01004', 0, '[Microsoft][ODBC SQL Server Driver]Fractional > truncation', 4579)\n"] > Trying 2004-03-11 10:29:20.00 > That seemed to work > > Maybe there's some option setting that will automatically truncate > fractional seconds, and I don't have it set? Can't find anything in the > documentation, though. FWIW, Transact-SQL docco says """Date and time > data from January 1, 1753 through December 31, 9999, to an accuracy of > one three-hundredth of a second (equivalent to 3.33 milliseconds or > 0.00333 seconds). Values are rounded to increments of .000, .003, or > .007 seconds, as shown in the table.""", so it should be capable of > sub-second resolution. Perhaps it just doesn't like values that require > rounding? > > > We can then look into adding code to truncate the fraction in > > timestamps for MS SQL Server ODBC drivers. > > > Well OK, I hope this helps. Thank you M.-A. and Steve for your responses. I tried Steve's suggestion of using the DateTimeFromTicks method and it seems to work. > If so, please provide us with the information from > connection.dbms_version > connection.dbms_name > connection.driver_name > connection.driver_version Like Steve, I couldn't find these attributes in the module. My MS SQL driver is newer than Steve's: SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 Thanks again for your replies. Let me know if I should check anything else on my setup. Chuck Bearden From mal at egenix.com Thu Mar 11 20:06:32 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4050B8B8.50605@egenix.com> Charles Bearden wrote: >>>If so, please provide us with the information from >>> >>>connection.dbms_version >>>connection.dbms_name >>>connection.driver_name >>>connection.driver_version >>> >> >>Are these connection attributes a recent addition? My 2.0.5 doesn't > > have > >>them, nor any reference to them in the documentation. Or have I >>misunderstood what I'm supposed to be reporting? Ah, yes. These are new in version 2.1 because we had to start putting in driver specific work-arounds into the code to deal with problems like the ones you are seeing. >>Anyway, from the ODBC driver info applet: >> >>SQL Server; Version 2000.80.194.00; SQLSRV32.DLL; 8/6/2000 >>SQL Server; Version 2000.81.9031.38; SQLSRV32.DLL; 3/11/2003 >> >>Maybe there's some option setting that will automatically truncate >>fractional seconds, and I don't have it set? Can't find anything in > > the > >>documentation, though. FWIW, Transact-SQL docco says """Date and time >>data from January 1, 1753 through December 31, 9999, to an accuracy of >>one three-hundredth of a second (equivalent to 3.33 milliseconds or >>0.00333 seconds). Values are rounded to increments of .000, .003, or >>.007 seconds, as shown in the table.""", so it should be capable of >>sub-second resolution. Perhaps it just doesn't like values that > > require > >>rounding? Well, it's only giving a warning that rounding has taken place. That's nothing serious and the INSERT will have actually made it to the database if you do a .commit(). The problem with MS SQL Server ODBC driver is that it is providing too many of these warnings. Note that there's an option to compile mxODBC with *all* warnings disabled. You have to change the code in mxCOMMERCIAL.py like this to enable it and then recompile the package using "python setup.py install": if sys.platform[:3] == 'win': ext_modules[len(ext_modules):] = [ Extension('mx.ODBC.Windows.mxODBC', ['mx/ODBC/Windows/mxODBC.cpp', 'mx/ODBC/Windows/mxSQLCodes.cpp', ], include_dirs=['mx/ODBC/Windows'], # Change these lines... define_macros=[('MS_ODBC_MANAGER', None), ('DONT_REPORT_WARNINGS', None)], # ...end of fix libraries=['odbc32'] ), ] > My MS SQL driver is newer than Steve's: > > SQL Server; Version 2000.81.9042.00; SQLSRV32.DLL; 10/27/2003 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Thu Mar 11 20:59:44 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] ZopeDA columninfos() Problems In-Reply-To: References: Message-ID: <4050C530.2030501@egenix.com> Joseph Kocherhans wrote: > I'm developing a zope product, and when I try to call the columninfos() > method on a connection object I get the following traceback: > > Traceback (most recent call last): > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 100, in publish > request, bind=1) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\mapply.py", > line 88, in mapply > if debug is not None: return debug(object,args,context) > File "C:\Program Files\Zope-2.7.0\lib\python\ZPublisher\Publish.py", > line 40, in call_object > result=apply(object,args) # Type s to step into published > object. > File "C:\zope\devinstance\Products\CMFDBSchemaBrowser\dbschema.py", > line 28, in getColumns > > File "Products\mxODBCZopeDA\ZopeDA.py", line 1582, in columninfos > NameError: global name 'self' is not defined > > I'm doing something like > conn = mymxZodbcConnection.get_connection() > return conn.columninfos() > > I'm not sure where to start here since I can't see the source code ;) Looks like you have found a bug. We'll add a fix to the next release. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 11 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 87 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at egenix.com Sat Mar 13 17:55:24 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4050B8B8.50605@egenix.com> References: <4050B8B8.50605@egenix.com> Message-ID: <40533CFC.3070705@egenix.com> >>> Maybe there's some option setting that will automatically truncate >>> fractional seconds, and I don't have it set? Can't find anything in the >>> documentation, though. FWIW, Transact-SQL docco says """Date and time >>> data from January 1, 1753 through December 31, 9999, to an accuracy of >>> one three-hundredth of a second (equivalent to 3.33 milliseconds or >>> 0.00333 seconds). Values are rounded to increments of .000, .003, or >>> .007 seconds, as shown in the table.""", so it should be capable of >>> sub-second resolution. Perhaps it just doesn't like values that require >>> rounding? Still looking for a good work-around to apply to the next release... Would rounding to the nearest hundreth of a second help ? E.g. does the driver complain about values such as 0.01, 0.02, 0.03, 0.04 seconds ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 13 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2004, G?teborg, Sweden 85 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From sholden at holdenweb.com Sun Mar 14 10:16:45 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <40533CFC.3070705@egenix.com> Message-ID: I just ran a test. Despite the fact that Microsoft suggest otherwise, most "hundredth-second" intervals fail - I ran a test, adding i/100 to an integral ticks value for i in range(99). The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). So, rounding to the nearest 250 mS should work, for some value of "work". regards Steve > -----Original Message----- > From: egenix-users-bounces@lists.egenix.com > [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of > M.-A. Lemburg > Sent: Saturday, March 13, 2004 11:55 AM > To: M.-A. Lemburg > Cc: Egenix-Users@Lists.Egenix.Com; sholden@holdenweb.com > Subject: Re: [egenix-users] "right truncation" warning in > mx.ODBC.Windows > > > >>> Maybe there's some option setting that will automatically truncate > >>> fractional seconds, and I don't have it set? Can't find > anything in the > >>> documentation, though. FWIW, Transact-SQL docco says > """Date and time > >>> data from January 1, 1753 through December 31, 9999, to > an accuracy of > >>> one three-hundredth of a second (equivalent to 3.33 > milliseconds or > >>> 0.00333 seconds). Values are rounded to increments of > .000, .003, or > >>> .007 seconds, as shown in the table.""", so it should be > capable of > >>> sub-second resolution. Perhaps it just doesn't like > values that require > >>> rounding? > > Still looking for a good work-around to apply to the next > release... > > Would rounding to the nearest hundreth of a second help ? > E.g. does the driver complain about values such as 0.01, > 0.02, 0.03, 0.04 seconds ? > > -- > Marc-Andre Lemburg > eGenix.com > > Professional Python Services directly from the Source (#1, > Mar 13 2004) > >>> Python/Zope Consulting and Support ... > http://www.egenix.com/ > >>> mxODBC.Zope.Database.Adapter ... > http://zope.egenix.com/ > >>> mxODBC, mxDateTime, mxTextTools ... > http://python.egenix.com/ > ______________________________________________________________ > __________ > EuroPython 2004, G?teborg, Sweden > 85 days left > > ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for > free ! :::: > > > ______________________________________________________________ > _________ > eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From mal at egenix.com Mon Mar 15 15:41:09 2004 From: mal at egenix.com (M.-A. Lemburg) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: References: Message-ID: <4055C085.50804@egenix.com> Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Jim.Vickroy at noaa.gov Tue Mar 16 12:18:27 2004 From: Jim.Vickroy at noaa.gov (Jim Vickroy) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: <4055C085.50804@egenix.com> Message-ID: I too, thought I reported this problem some time in the **distant** past, but maybe I am mistaken . Anyway, MS SQL Server has a time resolution of 3.33 milliseconds; see for example: http://www.databasejournal.com/features/mssql/article.php/1442361#part_4 My experience has been that trying to press that limit still triggers occassional warnings; truncating mx.DateTime objects to centi-seconds for insertion in MS SQL Server definitely works with the two versions (6, 7) I have encountered. -- jv -----Original Message----- From: egenix-users-bounces@lists.egenix.com [mailto:egenix-users-bounces@lists.egenix.com]On Behalf Of M.-A. Lemburg Sent: Monday, March 15, 2004 7:41 AM To: sholden@holdenweb.com Cc: Egenix-Users@Lists.Egenix.Com Subject: Re: [egenix-users] "right truncation" warning in mx.ODBC.Windows Steve Holden wrote: > I just ran a test. Despite the fact that Microsoft suggest otherwise, > most "hundredth-second" intervals fail - I ran a test, adding i/100 to > an integral ticks value for i in range(99). > > The only ones that worked were the quarter-seconds (0.25, 0.5, 0.75). > So, rounding to the nearest 250 mS should work, for some value of > "work". Thanks for checking. Unless we find a better alternative, I guess rounding to the nearest quarter of a second is the way to go... or maybe we can just silence the warning in this particular case. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 15 2004) >>> Python/Zope Consulting and Support ... http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ Python UK 2004, Oxford, UK 31 days left EuroPython 2004, G?teborg, Sweden 83 days left ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: _______________________________________________________________________ eGenix.com User Mailing List http://www.egenix.com/ http://lists.egenix.com/mailman/listinfo/egenix-users From sholden at holdenweb.com Tue Mar 16 14:40:31 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] "right truncation" warning in mx.ODBC.Windows In-Reply-To: Message-ID: [Jim Vickroy] > I too, thought I reported this problem some time in the > **distant** past, > but maybe I am mistaken . > > Anyway, MS SQL Server has a time resolution of 3.33 > milliseconds; see for > example: > > http://www.databasejournal.com/features/mssql/article.php/1442 > 361#part_4 > > My experience has been that trying to press that limit still triggers > occassional warnings; truncating mx.DateTime objects to > centi-seconds for > insertion in MS SQL Server definitely works with the two > versions (6, 7) I > have encountered. > More information which I forwarded to Marc-Andre earlier but omitted to copy to this list ... [mal] > Thanks for checking. Unless we find a better alternative, I > guess rounding to the nearest quarter of a second is the > way to go... or maybe we can just silence the warning in this > particular case. > Hold on! I have just run a program to transfer a table from one copy of SQL Server 2000 to another (Enterprise to Personal, if it matters, I don't know). Table definition is the same on both machines ... I had Enterprise manager script them both to verify this. I find that the sending system (version 8.00.534 (SP2)) is producing datetime values by defaulting the column in question to the value GETDATE(). The receiving instance of SQL Server 2000 (version 8.00.760 (SP3)) can't store these datetimes because of the fractional values! Here's the list of values I see from the sending instance in SQL Squery Analyzer: 2004-03-08 14:43:31.647 2004-03-08 15:19:25.853 2004-03-08 15:21:03.847 2004-03-08 15:22:11.483 2004-03-08 15:27:14.830 2004-03-08 15:30:57.210 2004-03-08 15:33:52.070 2004-03-08 15:38:47.587 2004-03-09 10:29:56.187 2004-03-09 10:31:01.040 2004-03-09 10:31:48.677 2004-03-09 10:37:22.677 2004-03-10 10:40:00.060 2004-03-11 10:49:12.030 2004-03-12 10:05:17.170 Clearly there is some granularity there, but just as clearly it isn't 0.25 seconds. I have no idea what gives here, as there don't appear to be any specific option settings to control this behavior. When I print the datetime objects from the read of this table I see: (2, , (3, , (4, , (5, , (6, , (7, , (8, , (9, , (10, , (11, , (12, , (13, , (14, , (15, , (16, , So, it could be that the problem is truncation on import into DateTime rather than anything else. Don't know whether this will help, but it's another data point at least. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From sholden at holdenweb.com Tue Mar 16 16:18:25 2004 From: sholden at holdenweb.com (Steve Holden) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] Cygwin mx-commercial-2.0.6, anyone? Message-ID: OK, I hope this can be fed forward into 2.1 and onwards. The last time I worked this out I think it got lost due to a mail glitch, and neither Marc-Andre nor I could remember how to fix the problem. I finally dredged up the missing steps, and I have mx-commercial-2.0.6 running on Cygwin. I'll leave the engineering to more experienced hands. The clue was remembering Marc-Andre saying he should get rid of the C++. That's what was required! Changes: /mxCOMMERCIAL.py: Change .cpp file references to refer to .c files /mx/ODBC/Windows: Rename .cpp files to .c Define min(i,j) function in mxODBC.c (or link to suitable one) I used: static int min(int x, int y) { if (x <= y) { return x; } return y; } Even *I* know that much C. The build then runs like a dream. I haven't yet tried rebuilding the same setup on native Windows, so I can't guarantee I haven't broken that load. regards -- Steve Holden http://www.holdenweb.com/ ReportLab Enterprise Publishing Solutions http://www.reportlab.com/ Chairman, PyCON DC 2004 http://www.pycon.org/ Telephone: +1-800 494 3119 Fax: +1 703 278 8289 From rra42 at yahoo.co.uk Tue Mar 30 14:25:08 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: Message-ID: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Dear List, I use Zope 2.5.1 and have mxDateTime installed in $ZOPEDIR/lib/python2.1/site-packages/mx... Version is 2.0.3. Anytime I try to import mxDateTime into a Script(Python) product in Zope, I get unauthorized errors. Is it possible to access mxDateTime from a Script(Python) or must I use External Methods? Thank you, rob For information, I have psycopg installed and that is working very well with mxDateTime. ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Tue Mar 30 15:30:08 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330122508.75187.qmail@web20903.mail.yahoo.com> References: <20040330122508.75187.qmail@web20903.mail.yahoo.com> Message-ID: <20040330143008.3437.29@wonderland.1080635838.fake> On 2004-03-30 at 14:25:08 [+0200], robin abbi wrote: > Dear List, > > I use Zope 2.5.1 and have mxDateTime installed in > $ZOPEDIR/lib/python2.1/site-packages/mx... > Version is 2.0.3. > > Anytime I try to import mxDateTime into a > Script(Python) product in Zope, I get unauthorized > errors. > > Is it possible to access mxDateTime from a > Script(Python) or must I use External Methods? Yes, you can make any kind of Python module available to your scripts. See the README in the PythonScripts folder. Regards Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From rra42 at yahoo.co.uk Tue Mar 30 16:50:01 2004 From: rra42 at yahoo.co.uk (=?iso-8859-1?q?robin=20abbi?=) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] mxDateTime and Script(python) in Zope 2.5.1 In-Reply-To: <20040330143008.3437.29@wonderland.1080635838.fake> Message-ID: <20040330145001.45904.qmail@web20917.mail.yahoo.com> > > Is it possible to access mxDateTime from a > > Script(Python) or must I use External Methods? > > Yes, you can make any kind of Python module > available to your scripts. See > the README in the PythonScripts folder. > 1. in $ZOPEDIR/lib/python/Products/ created GlobalModules 2. created __init__.py with allow_modules('mx.DateTime') 3. restarted zope 4. created python script: from mx.DateTime import mxDateTime eod=mxDateTime.now() print eod return printed 5. Called script. Error: You are not allowed to access now in this context. I've tried a wide range of variations on the allow_modules argument : 'mx', 'mx.DateTime', 'mx.DateTime.mxDateTime' including combinations of the above, with restarts and enough deliberate errors to know that the __init__.py script is being read. I must be overlooking something obvious. Any help gratefully received. Thanks, rob ________________________________________________________________________ Yahoo! India Insurance Special: Be informed on the best policies, services, tools and more. Go to: http://in.insurance.yahoo.com/licspecial/index.html From charlie at egenix.com Wed Mar 31 14:11:45 2004 From: charlie at egenix.com (Charlie Clark) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] RE: [egenix-info] RE: [egenix-support] (No id YET) In-Reply-To: <007c01c41697$a69b60d0$9900a8c0@mblaptop> References: <007c01c41697$a69b60d0$9900a8c0@mblaptop> Message-ID: <20040331131145.2313.7@wonderland.1080720580.fake> On 2004-03-30 at 22:43:26 [+0200], Morten Bech wrote: > Well it works now, but ? > > Could you please send me a very little dtml doc on getting something > from a DB ? > > Before i used another Oracle product through the ZMI and there you wrote > your sql called it through dtml and that was it. Im a bit confused about > what to do now. Nothing in your manual describes it with a decent > example or am i wrong ? Hi Morten, I'm cc'ing this to our users' list and also to the Zope-DB list as we don't generally provide this kind of support. If you're very new to Zope then you should take the time to look at the Zope book which is available online and has lots of examples on how to do things with Zope. But here are few steps to get you on your way: create a ZSQL method with SQL code to collect something from a database eg. SELECT name, age FROM person assuming you've got a relation called person with attributes name, and age. Then you can add a ZSearchInterface to use this query to generate a report. We suggest you dive straight on into PageTemplates rather than DTML which is considered by most to be deprecated. Assuming your ZSQL method is called qPerson, a ZPT might look something like this.
Name Age
Good luck! Charlie Clark -- 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 mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From todd at flemingcnc.com Wed Mar 31 11:08:58 2004 From: todd at flemingcnc.com (todd) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] Installation woes Message-ID: <20040331140944.M30618@www.flemingcnc.com> First my configuration: Windows XP Zope 2.7.0 Zope installation directory is C:\Program Files\Zope-2.7.0 Instance directory is C:\Zope Zope on my system is a fresh install, not an upgrade. I didn't install the instance as a service; I use runzope.bat The files I downloaded: Zope-2.7.0-win32.exe (from zope.org) egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip (from egenix) The first problem I ran into is conflicting installation instructions. http://www.egenix.com/files/python/mxODBC-Zope-DA.html says this: 3. Unzip the distribution in the Zope Instance's home directory (i.e. where you find the Zope's lib/, bin/, etc. directories). The email sent with my commercial license says this: * Unzip the binary distribution of the package in the Zope installation's home directory (ie. where you find the Zope's lib/, bin/, etc. directories). Ok, where should I put it? The installation directory or the instance directory? Why do the instructions call these "home" directories? home directories, under both UNIX and Windows, refer to user directories, not product directories. Try 1 ===== I first extracted the distribution into Zope's installation directory, but ran into trouble with this instruction: 5. Change to the first license key subdirectory and copy the two files "license.py" and "license.txt" to the following directory in your Zope Instance installation: (Zope Instance Directory)/lib/python/mx/ODBC This directory didn't exist so I made it (C:\Zope\lib\python\mx\ODBC) and put the 2 files there. eGenix mxODBC Zope DA: trying Windows interface... failed: initialization of module mxODBC failed (mx.ODBC.Windows.LicenseError:mx.ODBC.license could not be loaded; please visit the http://www.egenix.com/ web-site to obtain a license file or write to licenses@egenix.com for information.) Try 2 ===== I removed the Zope installation and instance folders and reinstalled from scratch. I extracted the adaptor distribution into my instance directory (c:\Zope). I then started the instance without installing the license files. It started up with no errors; uh-oh, it must not be loading the adaptor. I shut it down, copied the license files to C:\Zope\lib\python\mx\ODBC, and restarted. I went into the management interface. "egenix mxODBC Database Connection" was NOT in the drop-down box for add. Try 3 ===== I shutdown the instance and extracted the adaptor distribution into C:\Program Files\Zope-2.7.0 . ***It is now extracted into both the installation and instance directories*** 2004-03-31T14:44:03 INFO(0) Zope New disk product detected, determining if we need to fix up any ZClasses. Woohoo! It might be working! "egenix mxODBC Database Connection" is now in the drop-down list. Summary ======= 1. The installation instructions in http://www.egenix.com/files/python/mxODBC-Zope-DA.html and the license email conflict. 2. Neither set of installation instructions work; I had to unzip the distribution into both the installation and instance directories. From todd at flemingcnc.com Wed Mar 31 11:15:42 2004 From: todd at flemingcnc.com (todd) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] Autoreply woes In-Reply-To: References: Message-ID: <20040331151051.M3785@www.flemingcnc.com> Mailing list owner: please disable this guy's account. ---------- Forwarded Message ----------- From: Tim Golden To: todd Sent: Wed, 31 Mar 2004 21:09:20 +0100 Subject: Out of Office AutoReply: [egenix-users] Installation woes I am back in on Friday 2nd April 2004. If you need help, please contact another member of the IT Development team or talk to the IT Helpdesk. ------- End of Forwarded Message ------- From todd at flemingcnc.com Wed Mar 31 11:52:11 2004 From: todd at flemingcnc.com (todd) Date: Fri Mar 31 16:33:43 2006 Subject: [egenix-users] Permission woes Message-ID: <20040331153539.M5210@www.flemingcnc.com> My configuration: Windows XP Zope 2.7.0 egenix-mxodbc-zopeda-1.0.8.win32-py2.3.zip I created an mxODBC Database Connection (called "crc_db") to an existing Access database. I created Z SQL Methods and sucessfully called them from a Python script. However, I can't get .execute() to work on a connection. Here is the code portion that's giving me problems: connection = container.crc_db.get_connection() building_rowset = connection.execute('select [Building ID] from [Buildings] where [Building Name] = ?', building)[1] Whenever this code runs, a dialog box pops up in the web browser asking the user to log in. The dialog doesn't accept my Zope account (user todd). Escaping from the dialog produces this message: Error Type: Unauthorized Error Value: You are not allowed to access 'execute' in this context I tried giving the script the Manager and Owner proxy roles, but this didn't change the behavior. The script, the connection, and the containing folder all belong to user todd.