bill anderson <bil-@libc.org> wrote: original article:http://www.egroups.com/group/zope/?start=26253
Hung Jung Lu wrote:
My experience with SyBase is that the adapter development is kind of slow, and only Linux platform is supported. And currently it has some glitches with some data types (decimal with 10 or more digits), it does not support stored procedures, and the implementation in Zope 2.1.4 crashes when you have date fields ending between 59 and 60 seconds (e.g: 59.23 sec). Also, when there is database problem, the adapter very often just hangs and lock the database out, requiring a Zope reboot.
Can you provide more specific detials? I am running two seperate systems with Sybase, one of which is pounded on pretty hard, with zero problems.
Sure, you just need to trace my previous postings. :) SyBase adapter has two specific problems that I have ran into. They are both 100% reproduceable and both have been reported to the Collector. One of them is now fixed for Zope 2.1.5 (the _validTime thing.) The other one still sits still waiting for Digicool to fix it. If I say the development of the adapter has been slow, it's because it's been slow. If I alone have been able to find (and fix) two problems and one limitation, somehow I don't think they are the only problems and limitation. :) Some of the bugs are later found independently by other people, too. (See below.) Many people also say that they have zero problems with Microsoft Windows. I guess they just have been lucky. Ha ha. But just because one person is lucky, it doesn't mean the rest of the world is equally lucky. :) Let me teach you how to para-phrase your question: "Can you provide more specific details? I am running two separate system with Sybase, and I would like to know more about these problems." Very nice. The following are three articles in chronological order. regards, Hung Jung ============================================================================== "hung jung lu" <hungjungl-@hotmail.com> wrote: original article:http://www.egroups.com/group/zope/?start=22495
From: Christopher Petrilli <petrilli@digicool.com>
Can you please specify what the exact behaviour problem IS? We treat any NUMBER data type with DECIMAL(10,0) or greater as a python long because it can not be represented accurately in a 32-bit integer. The option (as was treated before) is to return a float, but this is losing accuracy.
----------------------------------------------------------------
:) Sure enough, the DECIMAL data type problem persists in SybaseDA-2.0b2.
----------------------------------------------------------------
:) I nagged quite a bit in the zope mailing list about the SybaseDA DECIMAL data type problem, even posted a patch for it. Chris McDonough was kind enough to send everything to the Collector, too. The relevant threads can be views at Egroups.com under
http://www.egroups.com/group/zope/showthread.html?start=21025 http://www.egroups.com/group/zope/showthread.html?start=21108
----------------------------------------------------------------
It is very easy to cause the crash. Install your SybaseDAv2, restart Zope, create (add) an instance of "Sybase DataBase Connection", click on it, make sure that is it connected. Now, go to the "Test" tab, issue the SQL command:
create table test (id decimal(10))
Hit "Submit Query". Good. The table is created. Now, go to the "Test" tab again, issue the SQL command:
select * from test
Voila, crash.
Error Type: sy_occ.error Error Value: Invalid buffer element type ... File /usr/local/bs_zope/lib/python/Products/SybaseDAv2/db.py, line 239, in query sy_occ.error: (see above)
The error does not happen when you have 9 or fewer digits in your DECIMAL data type declaration.
============================================================================== "hung jung lu" <hungjungl-@hotmail.com> wrote: original article:http://www.egroups.com/group/zope/?start=22504
Hi,
There is a bug in \lib\DateTime\DateTime.py, this particularly concerns Sybase database users. In the lines:
def _validTime(self,h,m,s): return h>=0 and h<=23 and m>=0 and m<=59 and s>=0 and s<=59
Please change s<=59 to s<60.
This bug is causing Sybase to crash whenever a table contains a date value with s>59, e.g: s=59.23
regards,
Hung Jung (I have submitted to the Zope bug collector)
______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
============================================================================== brian takashi hooper <bria-@garage.co.jp> wrote: original article:http://www.egroups.com/group/zope/?start=23843
Hi there -
(I've taken the liberty of also submitting these bugs to the Collector...)
I think I found a bug with ZSybaseDA (the newest version) - here's the deal:
I have a table in Sybase with a DateTime field. When I get a time back from it, the value of the field gets set in sy_occbf.c to something like:
(2000, 2, 21, 22, 31, 59.63)
The second value is being set to double (on purpose, looking at the sy_occbf.c code).
The problem with this is that DateTime doesn't correctly validate floating point hour/min/seconds. The documentation string seems to say that DateTime can take (from the DateTime 1.43 doc string)
"floating point, positive or negative offsets in units of hours, minutes, and days,"
for the fourth, fifth and sixth arguments - should this instead be
"positive integer values for hours, minutes, and positive floating point values for seconds"?
I think the latter might be simpler and easier to understand... Anyways, right now what DateTime is closer to this anyway - it validates times by calling self._validTime(h, m, s), which is defined:
def _validTime(self,h,m,s): return h>=0 and h<=23 and m>=0 and m<=59 and s>=0 and s<=59
I was lucky enough to stumble on the case where 59 < s < 60; this could be taken care of by:
def _validTime(self,h,m,s): return h>=0 and h<=23 and m>=0 and m<=59 and s>=0 and s<60.0
Of course, it's obvious that negative hour or minute offsets are also not going to work...
The Sybase DA end of the thing - as I started out by saying, I noticed all this because the results that Sybase returned didn't convert correctly. Specifically, an exception was raised where SybaseDA was in the middle of handling a fetched result set:
(in db.py, DA.query()...)
if type(v) is TupleType: v=apply(converters[t], v)
Because an exception is raised in the middle of fetching a result set, the command structure still has results left to fetch - this makes the next call to cm.ct_command() fail - Sybase says, on the next query:
ct_command(): user api layer: external error: This routine cannot be called while results are pending for a command that has been sent to the server.
Which happens because we never got to cancel the previous result set.
How about running the conversions in a try/except, for safety, like:
try: if type(v) is TupleType: v=apply(converters[t], v) except: cm.ct_cancel(sy_occ.CS_CANCEL_ALL) raise Error("Results field conversion error: converter=%s, v=%s" % \ (str(converters[t]), str(v)))
I don't think there is anything else, but anything that might throw an exception in the error processing loop should also probably be wrapped to call ct_cancel so that the command structure is ready to go on the next call.
Well, that's all. This'll be in the Collector as soon as I can write it, too.
-Brian Hooper
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com