Hmm, without looking at the code I would guess that they define new
LOB locator variables for each of the rows that are fetched. That
seems to me to be a lot of overhead for very little gain -- unless you
can give me some valid reason for why fetchall() is a good idea when
dealing with LOBs. :-)
In general, I would suggest the following idiom:
for value_1, value_2, lob in cursor:
DoStuff(value_1, value_2, lob.read())
or some such. In other words, use the iterator which ensures that
you're using as little memory as possible and doesn't have the issue
with the LOB locators.
On 7/15/05, Hamish Lawson <ham...@gm...> wrote:
> Hello Anthony
>=20
> The cx_Oracle manual explains that calling fetchall when the resultset
> contains LOBs will raise an exception because the LOB locators would
> get invalidated by the next fetch. However DCOracle2 lets you call
> fetchall and still read the LOBs in each of the returned rows. I don't
> know what approach DCOracle2 uses to achieve this, but is it something
> you could borrow?
>=20
>=20
> Hamish Lawson
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>
|
