[Zope] DCOracle2 and Clob object problem

[Matthew T. Kromer]

Mateusz wrote:

> Hi!
> I have problem with dcoracle 2 and clob object. I'm working under:
> Zope Version  (Zope 2.5.1 (binary release, python 2.1, linux2-x86), 
> python 2.1.3, linux2)  Python Version  2.1.3 (#1, Apr 15 2002, 
> 11:13:45) [GCC 2.7.2.3]  System Platform  linux2  (RedHat 7.1)
>
> When i'm testing function (which is below) under win 2000 it works 
> properly, but under RedHat7.2 it prints "None" as a data object, but 
> when i print object ala, i see :
> [[<LobLocator object at 0x8b59ab8>]]
> so i'm sure that there is an clob object. This is my test function. I 
> think method "read()" does't work properly under linux?
> Do you have any suggestions?
>
> ==========
> def test1():
>       db = DCOracle2.connect("p_engine/qwerty@neodev")
>       c = db.cursor()
>       c.execute("select html_clob from tags_tokens where id='37'")
>       ala =  c.fetchone()
>       lob = ala[0]
>       data = lob.read()
>       print data
>       c.close()
>       return data


That should work.  Why it doesn't is strange.  The only way to track 
that down is usually to turn on tracing, e.g. setenv 
DCO2TRACELOG=dco2.tracelog; setenv DCO2TRACEFLAGS=255 and restart Zope, 
then I can look in the trace log to see what the length of the LOB was. 
 It sounds like the LOB is being returned by Oracle as having length 
zero on Linux.

Note that I am fairly sure I added an implicit read to DCOracle2 LOBs 
when accessed through  a DCOracle2 Connection object in Zope -- trying 
to do a str() of the LOB will cause it to be read, which is normally 
what you want anyway.

That implicit read does NOT hold true when you get the lob directly from 
a cursor fetch mechanism, it's applied at the Zope layer.


-- 
Matt Kromer
Zope Corporation  http://www.zope.com/