Re: [Zope-DB] Returning values from Oracle function/procedure withZSQLMethod

2005-04-12 Thread Matthew T. Kromer
Chris Withers's branch of DCOracle2 has some changes that help the connection pooling problem. The issue basically is that the Zope adapter for DCOracle2 is fairly old and crusty. I think Jim's correct when he suggests doing your own pool management from a module. All that the DA is supposed

Re: [Zope-DB] Returning values from Oracle function/procedure withZSQLMethod

2005-04-21 Thread Matthew T. Kromer
On Apr 19, 2005, at 4:24 AM, Chris Withers wrote: Matthew T. Kromer wrote: Chris Withers's branch of DCOracle2 has some changes that help the connection pooling problem. And rumour has it I'm going to get some serious time to work on this soon! Matt, you up for fixing any C-level bugs that crawl

Re: [Zope-DB] Installing DCOracle2 with Oracle 10g

2005-09-28 Thread Matthew T. Kromer
Not sure, but I think DCOracle2 includes both Python.h and stdio.h -- try removing stdio.h and making the python.h include the first include. On Sep 28, 2005, at 2:38 PM, Seth Gottlieb wrote: I have been trying to compile DCOracle2 and found the instructions from evstumpf at ucdavis.

Re: [Zope-DB] Installing DCOracle2 with Oracle 10g

2005-09-29 Thread Matthew T . Kromer
differently. On Sep 28, 2005, at 10:34 PM, Seth Gottlieb wrote: Thanks for responding. I commented out line 92: #include stdio.h and moved #include Python.h (which was around line 126) to the first of the includes. I still get the same error message. Anything else to try? Thanks, Seth Matthew T

Re: [Zope-DB] DCOracle2 on AIX5.2 -- issues

2006-03-15 Thread Matthew T . Kromer
It's probably the TRACE macro which is generating a lot of these messages, if you don't need to be able to do runtime tracing (for diagnostics) then you can tweak the #define TRACE(condition,args) to be a no-op macro -- just delete the body of the macro. On Mar 14, 2006, at 2:54 PM,

Re: [Zope-DB] Pitfall: mxODBCZopeDA and test runner in 2.9+

2006-10-13 Thread Matthew T. Kromer
On Oct 13, 2006, at 5:14 AM, Chris Withers wrote: I have to echo Jens' sentiments though: why not just ship .py files and be done with it? If I had to make a wild-ass guess, its because there's an indication that the mxodbc code would be misappropriated and proliferated outside of

Re: [Zope-DB] DCOracle2 with a Stored Procedure that Returns REFCURSOR / ORA TIMESTAMP DataType Issue

2007-03-20 Thread Matthew T. Kromer
Chances are good that the C code that is trying to construct the timestamp doesn't know how to convert it... A quick peek into the source code hints the code doesn't have a type converter for SQLT_TIMESTAMP, although there is a converter for SQLT_DAT (date). Putting a converter into the

[Zope-DB] Re: DCOracle2 TIMESTAMP DataType Issue

2007-03-22 Thread Matthew T. Kromer
would know if CONVERTOUTF (SQLT_DAT) is producing error or simply the absence of CONVERTOUTF (SQLT_TIMESTAMP) is causing it. Maan - Original Message - From: Matthew T. Kromer [EMAIL PROTECTED] To: Maan M. Hamze [EMAIL PROTECTED] Cc: zope-db@zope.org Sent: Tuesday, March 20, 2007 8