Some databases convert them to uppercase!
Oracle is a prominent example!
It took me once some ours to locate a bug resulting
from this "feature".
This reminds me of another post I did some time before, but
where nobody replied.
Shouldn't tags for creating
Oliver Bleutgen writes:
Shouldn't tags for creating sql-statements in ZSQL
(like dtml-sqltest) quote the variables by default in order
to prevent unexpected conversions by the database?
Did you check, that standard SQL supports quoted
names?
Even if it does, the proposed change will
Oliver Bleutgen writes:
Shouldn't tags for creating sql-statements in ZSQL
(like dtml-sqltest) quote the variables by default in order
to prevent unexpected conversions by the database?
Did you check, that standard SQL supports quoted
names?
First, I meant double quotes (") not
Cees de Groot writes:
Jon Prettyman [EMAIL PROTECTED] said:
If you are using ZSQLMethods and your database returns column names in
one case (UPPER) but you reference them with another (lower) it
appears that instances of SQLAlias get leaked.
Thanks for the info (and another reason to
Jon Prettyman [EMAIL PROTECTED] said:
If you are using ZSQLMethods and your database returns column names in
one case (UPPER) but you reference them with another (lower) it
appears that instances of SQLAlias get leaked.
Thanks for the info (and another reason to keep SQL names in lowercase ;-)).
If you are using ZSQLMethods and your database returns column names in
one case (UPPER) but you reference them with another (lower) it
appears that instances of SQLAlias get leaked.
Brian Lloyd has put Jim Fulton's fix in the 2.2.5b release that's up
on the site.
We were seeing thousands of
Are you using ZSQLMethods by any chance?
-jon
[EMAIL PROTECTED] (Cees de Groot) writes:
Our production Zope machine has developed a habit over Christmas where
it starts eating CPU and RAM (one Python thread on 100% CPU time, and
I've seen kernel messages indicating that Zope was killed
[EMAIL PROTECTED] said:
I've made zope inaccessible two different ways:
- passing bad data to ZDGChart - sending mail when MailHost is down
(i.e. the host it is supposed to connect to is not available)
It seems a bug in my virtual hosting code (a Python method that acts as the
AccessRule
Jon Prettyman [EMAIL PROTECTED] said:
Are you using ZSQLMethods by any chance?
Yes, why? (I think I've fixed /this/ problem, but if ZSQLMethods will
cause similar behaviour I'd like to be prepared :-))
--
Cees de Groot http://www.cdegroot.com [EMAIL PROTECTED]
GnuPG
Cees de Groot writes:
... excessive CPU/memory consumption ...
If you use Zope 2.2.x, you can try to access the debug tools
in the "Control Panel". They will show you, which request
is active (to more easily reproduce and analyse the problem)
and how the reference counts are changed.
Dieter
Turning on detailed logging at startup might help too... read about the -M
argument in the z2.py script and read my Howto regarding "How To Track Down
Hangs" at http://www.zope.org/Members/mcdonc/HowTos/DEBUG-LOG
"Cees de Groot" [EMAIL PROTECTED] wrote in message
92ghr3$jf3$[EMAIL
Dieter Maurer [EMAIL PROTECTED] said:
Cees de Groot writes:
... excessive CPU/memory consumption ...
If you use Zope 2.2.x, you can try to access the debug tools
in the "Control Panel". They will show you, which request
is active (to more easily reproduce and analyse the problem)
and how the
[EMAIL PROTECTED] said:
Turning on detailed logging at startup might help too... read about
the -M argument in the z2.py script and read my Howto regarding "How
To Track Down Hangs" at http://www.zope.org/Members/mcdonc/HowTos/
DEBUG-LOG
Thanks! That looks promising!
--
Cees de Groot
Our production Zope machine has developed a habit over Christmas where
it starts eating CPU and RAM (one Python thread on 100% CPU time, and
I've seen kernel messages indicating that Zope was killed because it
hit an out-of-memory condition which means it sat on ~500Mb RAM).
I'm completely in
14 matches
Mail list logo
