Re: [Zope] MySql connector error
Le Samedi 25 Août 2007 17:07, Kevin a écrit : Intermittently, I recieve an error *Shouldn't load state for 0xf5f137 when the connection is closed * This means there is somewhere a reference to a persistent object which keeps it past transaction commit, which is a bad behaviour. I implemented this object because the standard mysql database adapter would fail if the connection was idle for some time with a similar kind of error. I *think* the error you previously got was not the same, but a conection closed from regular ZMySQLDA. It is because only the query is protected against such error (it causes a reconnection query retry), but not the BEGIN query, which is of course issued first and causes the error to go up uncatched. I have a ZMySQLDA version which fixes this problem (an another tricky one), and it should get merged into upstream version in near future. You can grab it on: http://svn.erp5.org/erp5/trunk/products/ZMySQLDA/ Just one remark: a bug has been found in this version which causes problems if multiple connections with the same id exist in different places, due to a pooling mechanism used to fix the tricky bug. It will work just fine if you use site-scope unique ids - as it works for me - but you will get troubles if that's not the case. -- Vincent Pelletier ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] MySql connector error
Your right, the older mysql da I was using gave 'Shouldn't Load State When Connection is Closed'. It turns out that my DA is implemented correctly, but the database cursor is being persisted in another object(past transaction commit) as you noted. So, with some readjusting, the error seems resolvable. Thanks for the explanation! -Kevin Pelletier Vincent wrote: Le Samedi 25 Août 2007 17:07, Kevin a écrit : Intermittently, I recieve an error *Shouldn't load state for 0xf5f137 when the connection is closed * This means there is somewhere a reference to a persistent object which keeps it past transaction commit, which is a bad behaviour. I implemented this object because the standard mysql database adapter would fail if the connection was idle for some time with a similar kind of error. I *think* the error you previously got was not the same, but a conection closed from regular ZMySQLDA. It is because only the query is protected against such error (it causes a reconnection query retry), but not the BEGIN query, which is of course issued first and causes the error to go up uncatched. I have a ZMySQLDA version which fixes this problem (an another tricky one), and it should get merged into upstream version in near future. You can grab it on: http://svn.erp5.org/erp5/trunk/products/ZMySQLDA/ Just one remark: a bug has been found in this version which causes problems if multiple connections with the same id exist in different places, due to a pooling mechanism used to fix the tricky bug. It will work just fine if you use site-scope unique ids - as it works for me - but you will get troubles if that's not the case. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Deleting a file in Python
On Sat, Aug 25, 2007 at 07:35:06AM -0400, [EMAIL PROTECTED] wrote: but I can't figure out where context.* is documented. It depends what kind of object context is. To find out, you may find this product useful: http://plone.org/products/docfindertab Here is a good start reference for Zope 2 APIs... it was never finished or updated for zope later than 2.7, but it's a lot better than nothing: http://www.plope.com/Books/2_7Edition/AppendixB.stx -- Paul Winkler http://www.slinkp.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Help with DateTime.earliestTime()
On 8/27/07, Dieter Maurer [EMAIL PROTECTED] wrote: Andreas Jung wrote at 2007-8-26 21:23 +0200: ... If you can: use Python's datetime module. DateTime is broken in many ways. If it handles daytime saving and addition by some float days -- it will not have any chance... If it does not handle daytime saving -- then it misses an essential use case... Some problems come from the complexity of the real world and not from a particular implementation -- Dieter In this case it seems that the complexity is being added by the DateTime implementation. When given an int number of days and a DateTime that has no time element, DateTime should not convert everything down to seconds and account for DST that happens to occur during the period. When adding days + days, I'd expect to get a result that only considers days; not DST. So I agree with your earlier post that DateTime should treat int and float addition differently. It should also probably look at the DateTime and revert to integer math if there is no time element present. - Eric ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Help with DateTime.earliestTime()
Maurits van Rees wrote: Eric, on 2007-08-26: To work around this, I've modified the addition so that instead of adding 1 day, it adds 1.5 days. This extra half a day is removed by the theDateTime.earliestTime() call but is enough to overcome the DST addition problem. Ugly hack. I had the same problem once in the eXtremeManagement Plone product. For a monthly overview I needed to do something for every day of the month. I worked around it with the code below. day = 1 date = DateTime(2007, 10, 1) # 1 October 2007 while True: # skipped some lines irrelevant to the DateTime problem day += 1 try: date = DateTime(self.year, self.month, day) except: break Hm, that should probably be except DateTime.DateTime.DateError but there is not really anything else that can go wrong here. A ConflictError can go wrong here, which is an additional and important reason not to have a bare except. There are good reasons without that, as well. --jcc -- Connexions http://cnx.org Building Websites with Plone http://plonebook.packtpub.com ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Deploying with buildout (was: buildout, instancemanager, and eggs)
We have a Plone 3.0/Zope 2.10 application that we need to develop on, maintain and deploy to a ZEO server and multiple ZEO clients. Currently we use svn bundles of Zope and Plone and our own packages and products in one big svn:externals definition. We also use some more recent versions of certain products and packages than those included in the upstream svn:externals. For example: Zope svn://svn.zope.org/repos/main/Zope/branches/2.10 Zope/lib/python/zope/app/interface svn://svn.zope.org/repos/main/zope.app.interface/trunk/src/zope/app/interface Though I haven't seen any documentation to this effect, svn seems to treat the second svn:externals as a svn switch on svn up. So one question I have is how would I override the versions of some package like this using buildout? Another question I have is that there aren't releases for all the dependencies our application has. I'm wondering what the best way is to define a canonical release for deployment to our cluster. Ideally, we'd have a buildout (or whatever) on a staging server where we're testing the candidate for deployment and then when all tests pass that *exact* source should be deployed to the cluster. How might one do this without upstream releases? Is there a way to get buildout and setuptools to play together so that I can build a source distribution from the test passing buildout on staging? Is there a way I can have a buildout on each cluster node such that a simple ./bin/buildout will get the latest deployment release for that node? Ross ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope-dev] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Sun Aug 26 12:00:00 2007 UTC to Mon Aug 27 12:00:00 2007 UTC. There were 5 messages: 5 from Zope Unit Tests. Tests passed OK --- Subject: OK : Zope-2.7 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Aug 26 20:53:28 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-August/008246.html Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Unit Tests Date: Sun Aug 26 20:54:58 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-August/008247.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Aug 26 20:56:30 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-August/008248.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Aug 26 20:58:01 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-August/008249.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Unit Tests Date: Sun Aug 26 20:59:33 EDT 2007 URL: http://mail.zope.org/pipermail/zope-tests/2007-August/008250.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Options replacing DateTime with datetime!?
Andreas Jung wrote at 2007-8-26 20:31 +0200: ... Conversion between both is pretty much trivial. However I have no idea how this would solve the DateTime problem. So what are our DateTime problems? - an insane constructor with a parser trying to parse almost every date format in the world (with lots of guessing and dealing with ambiguousness) Which you cannot get rid of -- for backward compatibility. - an insane timezone handling Timezones *are* incredibly difficult. It is not DateTimes fault (although there are some bugs, almost surely easily fixable). - DateTime is doing way too much Which you cannot get rid of -- for backward compatibility. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Options replacing DateTime with datetime!?
Dieter Maurer wrote: Andreas Jung wrote at 2007-8-26 20:31 +0200: ... Conversion between both is pretty much trivial. However I have no idea how this would solve the DateTime problem. So what are our DateTime problems? - an insane constructor with a parser trying to parse almost every date format in the world (with lots of guessing and dealing with ambiguousness) Which you cannot get rid of -- for backward compatibility. - an insane timezone handling Timezones *are* incredibly difficult. It is not DateTimes fault (although there are some bugs, almost surely easily fixable). - DateTime is doing way too much Which you cannot get rid of -- for backward compatibility. I agree with Dieter. I acknowledge Andreas's heroic efforts trying to create a bridge between the two, but I do wonder if it's worth it. As Dieter said, we can't get rid of the cruft for BBB reasons (not only to support old code but old pickles as well!). The only thing we can gain here is a fix for those esoteric timezones bugs. That alone doesn't seem worth a risky operation like that. In my personal opinion, we should * use datetime for all the new stuff that we write, * provide a convenient way to convert DateTime objects into datetime, * create alternate APIs for all the APIs that work with DateTime objects (e.g. create a version of bobobase_modification_time that returns a datetime, same with the CMF DublinCore interface, etc.) * let DateTime rot forever Alexander Limi wrote: Dealing with the existing DateTime implementation has been pain since I started with Zope 2.0.1. I'd be willing to suffer some cleanup and compatibility work if it was fixed once and for all, as would anyone doing anything non-US-centric with dates, I imagine. A 'cleaner', much better working version (datetime) and time zone support (pytz) have been around for ever since Python 2.3 was released and supported by Zope 2 several years (!) ago. It was everybody's choice NOT to use it so far. As Andreas has pointed out, converting existing DateTime objects to datetime objects is trivial. In fact, what I've outline above isn't much work (far less than what Andreas would have to do, I would assume) and could've done a long time ago already. Given that you would be willing to suffer some ... compatibility work (meaning, adjusting to new APIs that return datetime instead of DateTime objects or adjusting your code to convert DateTimes to datetimes), this sounds like solution that you' should be happy with, too. -- http://worldcookery.com -- Professional Zope documentation and training ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Options replacing DateTime with datetime!?
Philipp von Weitershausen wrote at 2007-8-27 22:11 +0200: ... In my personal opinion, we should * use datetime for all the new stuff that we write, * provide a convenient way to convert DateTime objects into datetime, * create alternate APIs for all the APIs that work with DateTime objects (e.g. create a version of bobobase_modification_time that returns a datetime, same with the CMF DublinCore interface, etc.) * let DateTime rot forever +1. And, the new version of bobobase_modification_time should have a more senseful name. ... A 'cleaner', much better working version (datetime) and time zone support (pytz) have been around for ever since Python 2.3 was released and supported by Zope 2 several years (!) ago. It was everybody's choice NOT to use it so far. Not sure whether everybody's choice is correct. I believe that datetime is not even importable in TTW code and datetime objects not accessible in TTW code -- at least, they have not been until recently... -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Options replacing DateTime with datetime!?
On 27 Aug 2007, at 22:25 , Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2007-8-27 22:11 +0200:
...
In my personal opinion, we should
* use datetime for all the new stuff that we write,
* provide a convenient way to convert DateTime objects into datetime,
* create alternate APIs for all the APIs that work with DateTime
objects
(e.g. create a version of bobobase_modification_time that returns a
datetime, same with the CMF DublinCore interface, etc.)
* let DateTime rot forever
+1.
And, the new version of bobobase_modification_time should have
a more senseful name.
Absolutely.
...
A 'cleaner', much better working version (datetime) and time zone
support (pytz) have been around for ever since Python 2.3 was
released
and supported by Zope 2 several years (!) ago. It was everybody's
choice
NOT to use it so far.
Not sure whether everybody's choice is correct.
I believe that datetime is not even importable in TTW code
and datetime objects not accessible in TTW code -- at least,
they have not been until recently...
allow_module('datetime') is all you had to do. Ok, admittedly, pure-
TTW developers who can't or won't touch filesystem code were out of
luck, but everybody who *knew* about datetime and wanted to use it
could have done so.
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-DB] updating fields in a zsql method programmatically
Here's the scenario:
1. insertNew is a Z SQL Method for creating a new record in pgsql table1
Argument list = field1, field2, field3
SQL Query:
INSERT INTO table1 (field1, field2, field3)
VALUES (
dtml-sqlvar field1 type=string,
dtml-sqlvar field2 type=string,
dtml-sqlvar field3 type=string)
2. call_insertNew is a python script that is called as an After
Validation Script by a pfg form
request = container.REQUEST
RESPONSE = request.RESPONSE
form = request.form
changed_field1 = form.get('field1')
changed_field1 = a new computed value
field1 = changed_field1
#create a new record with form field results for field2 field3, and a
computed value for field1
context.insertNew()
*
It's easy to insert and update Z SQL Methods directly from form field
results.
It's easy to read form field results (e.g. request.field2) and do
comparisons, etc.
I am struggling to understand how one can change a form field result with a
computed value from a python script.
Either of the following returns an error:
form.get('field1') = changed_field1
request.field1 = changed_field1
and...
field1 = changed_field1
...the value doesn't get posted to the pgsql record. Instead the pgsql
field1 value remains what the request.field1 value was originally.
Any direction is appreciated... Jim
--
View this message in context:
http://www.nabble.com/updating-fields-in-a-zsql-method-programmatically-tf4335404.html#a12347343
Sent from the Zope - DB mailing list archive at Nabble.com.
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] updating fields in a zsql method programmatically
changed_field1 = a new computed value field1 = changed_field1 #create a new record with form field results for field2 field3, and a computed value for field1 context.insertNew() Obvious things are sometimes hardest to find ;) Try: field1 = changed_field1 context.insertNew(field1=field1) or even: context.insertNew(field1='something', field2=other_variable) It is more clear than getting values from context I think. -- Maciej Wisniowski ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] updating fields in a zsql method programmatically
I tried the techniques you suggested and it results in the same error -- KeyError: 'form.submitted' field1 = changed_field1 context.insertNew(field1=field1) -- I also tried the other technique and got the same error. I tried your technique with the following changes to my pfg (ploneformgen) for and Z SQL Method: 1. with field1, field2, field3 all included in the pfg (ploneformgen) form 2. with these same three fields excluded from the pfg form 3. with my Z SQL method argument as field1 4. with my Z SQL method argument as field1=field1 I just know that there has to be an easy solution to this problem. I'm assuming the form results are stored as an object represented as a dictionary. If so, then there must be a way for my python script to change the key | value pair for field1 before I call my Z SQL Method. Is this reasonable, or am I just going down a rat-hole? Thanks... Jim Maciej Wisniowski wrote: changed_field1 = a new computed value field1 = changed_field1 #create a new record with form field results for field2 field3, and a computed value for field1 context.insertNew() Obvious things are sometimes hardest to find ;) Try: field1 = changed_field1 context.insertNew(field1=field1) or even: context.insertNew(field1='something', field2=other_variable) It is more clear than getting values from context I think. -- Maciej Wisniowski ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db -- View this message in context: http://www.nabble.com/updating-fields-in-a-zsql-method-programmatically-tf4335404.html#a12356504 Sent from the Zope - DB mailing list archive at Nabble.com. ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] updating fields in a zsql method programmatically
Am 27.08.2007, 15:59 Uhr, schrieb onsombal [EMAIL PROTECTED]:
changed_field1 = form.get('field1')
changed_field1 = a new computed value
field1 = changed_field1
#create a new record with form field results for field2 field3, and a
computed value for field1
context.insertNew()
^
This is really bad as it undoes all your good work of checking the the
values in your script. All ZSQL methods also have access to the REQUEST
object by default so your ZSQL method sees context.REQUEST.field1. Way
back when ZSQL was developed support for request objects was given to ZSQL
to allow funky parameters in the URL as well as the other usual special
methods such as manage and edit. Personally I think this is a bad idea and
always pass my parameters in as named arguments as Maciej suggests or as a
dictionary for neatness if there is a lot of them.
Charlie
--
Charlie Clark
eGenix.com
Professional Python Services directly from the Source
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] updating fields in a zsql method programmatically
Am 27.08.2007, 21:59 Uhr, schrieb onsombal [EMAIL PROTECTED]: I'm assuming the form results are stored as an object represented as a dictionary. If so, then there must be a way for my python script to change the key | value pair for field1 before I call my Z SQL Method. Is this reasonable, or am I just going down a rat-hole? All form values are in the context.REQUEST.form dictionary which can overwrite to your heart's content. Charlie -- Charlie Clark eGenix.com Professional Python Services directly from the Source Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] updating fields in a zsql method programmatically
onsombal napisał(a): I tried the techniques you suggested and it results in the same error -- KeyError: 'form.submitted' You didn't tell about this kind of error before. Post a full traceback, please. I suppose that error is somewhere else... -- Maciej Wisniowski ___ Zope-DB mailing list Zope-DB@zope.org http://mail.zope.org/mailman/listinfo/zope-db
Re: [Zope-DB] updating fields in a zsql method programmatically
So, my script now works!! Thanks to everyone for your input. It is greatly
appreciated. Below is a quick summary of what I did and a relevant excerpt
of the working script.
1) I never was able to get passing the arguments via the context.Statement
to work. I'm sure it's something I've done wrong.
2) I successfully updated the context.REQUEST.form dictionary key:value pair
with my computed value. The computed value was to replace the blank
(hidden) 'fdbkurl' pfg form field with the url of a form object that was
copied from a standard-template to another folder, and then renamed. After
renaming, I re-indexed the object, and then captured its absolute url --
which I then used to update the dictionary key:value.
Code follows:
#copy, paste, rename std-survey to Folder
from Products.CMFCore.utils import getToolByName
urltool = getToolByName(context, portal_url)
portal = urltool.getPortalObject()
mydoc_folder = getToolByName(context, my-documents)
crm_folder = getToolByName(context, crm)
survey_folder = getToolByName(context, std-forms)
listing_folder = getattr(mydoc_folder, listings)
#manage_copyObjects(self, ids=None, REQUEST=None, RESPONSE=None)
cb_copy_data = survey_folder.manage_copyObjects([std-survey])
dest = getattr(listing_folder, tls_id)
#manage_pasteObjects(self, cb_copy_data=None, REQUEST=None)
#Paste previously copied objects into the current object.
#If calling manage_pasteObjects from python code,
#pass the result of a previous call to manage_cutObjects or
manage_copyObjects as the first argument.
dest.manage_pasteObjects(cb_copy_data)
#manage_renameObjects(self, ids=[], new_ids=[], REQUEST=None)
tls_folder = getattr(listing_folder, tls_id)
survey_id = survey + form.get('tls')
survey_title = Survey + form.get('tls')
survey_obj = getattr(tls_folder, std-survey)
tls_folder.manage_renameObjects(ids=[std-survey], new_ids=[survey_id])
survey_obj.setTitle(survey_title)
survey_obj.reindexObject()
fbkurl = survey_obj.absolute_url()
formresult['fbkurl'] = fbkurl
#create record in usdb listing table
context.listingsCreateRow()
And it works!
Charlie Clark-2 wrote:
Am 27.08.2007, 21:59 Uhr, schrieb onsombal [EMAIL PROTECTED]:
I'm assuming the form results are stored as an object represented as a
dictionary. If so, then there must be a way for my python script to
change
the key | value pair for field1 before I call my Z SQL Method. Is this
reasonable, or am I just going down a rat-hole?
All form values are in the context.REQUEST.form dictionary which can
overwrite to your heart's content.
Charlie
--
Charlie Clark
eGenix.com
Professional Python Services directly from the Source
Python/Zope Consulting and Support ...http://www.egenix.com/
mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
Try mxODBC.Zope.DA for Windows,Linux,Solaris,MacOSX for free !
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
--
View this message in context:
http://www.nabble.com/updating-fields-in-a-zsql-method-programmatically-tf4335404.html#a12359442
Sent from the Zope - DB mailing list archive at Nabble.com.
___
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
