At 12:29 AM 3/8/2001 -0500, David Jencks wrote:

>I'm not yet familiar with gdml, is the effect of the above code to set up
>two cursors ( in sql-speak), one in each database, traverse the cross
>product, sending all rows to the client, evaluate the join condition on the
>client, and do a row-by-row update in one of the databases? Or is the join
>condition evaluated on the server? I would guess the former, and the next
>big step is the latter???

Yes - it's the equivalent of nested cursors. The actual comparison
happens on the server of the outer loop and the client sees only the
matching pairs. If done correctly, it's the equivalent of a nested
loop join - only the required columns are moved from database2 to
database1 and only the desired results are sent to the client. If
done incorrectly, it's like a very badly optimized query.

> > > > >2) The UDF processing has no associated transaction context.
>.....
>I agree, I just don't see any way to get accurate answers without
>distributed transactions.

How nice to find someone who cares about accuracy. I thought
that read committed had taken over the world and close enough
was good enough. You're absolutely right, of course.

>Are you telling us that Borland abandoned a multiplatform distributed
>transaction manager in favor of the BDE?????????????????

Yup. Of course, we only handled distributed transactions across
InterBase and Oracle ...


Regards,

Ann
www.ibphoenix.com
We have answers.