Thanks, Ann

A couple of small further questions below,

On 2001.03.07 11:42:25 -0500 Ann W. Harrison wrote:
> Continuing the discussion:
>
> > > > >
> > > > >For example sybase support proxy table that is similar to this
> idea,
> > > > >and MsSql does not have problems to access more databases at all.
> > >
> > > Bitter as gall. InterBase doesn't have any trouble accessing several
> > > databases, but its SQL interface does. That's getting higher on the
> > > Firebird to do list.
> >
> >Is there any documentation on how this multidatabase access works? which
> >language? Is this the yvalve?
>
> There is documentation in the reproduction of the 1987 books
> in the Programmer's guide, but it explains how to use multiple
> databases, not how they work internally. The old data manipulation
> language (GDML) included a database alias that could be applied
> to a table.
>
> ready my_db.gdb as mine;
> ready your_db.gdb as yours;
>
> start transaction;
> for this in mine.table1
> for that in yours.table1
> with this.value1 = that.value1
> begin
> printf ("Here: %s %d" this.name, that.salary);
> if (this.salary < that.salary>
> modify mine.table1 using this.salary = that.salary;
> end;
> commit;
>
> The "ready" statements establish connections to the two
> databases. The "start transaction" includes the information
> to start transactions on both databases - and yes, it's handled
> at the Y-valve level. A single transaction handle is returned
> to the program.
>
> The commit turns into two calls: prepare and commit. The prepare
> call causes both databases to write recovery information and flush
> it to disk. Any deferred work is performed and everything is written
> out. The commit merely changes the transaction state - a one page
> write on each database. In the unlikely event of a failure after the
> completion of the prepare on one database and the completion of the
> commit on all databases, gfix can file the recovery information and
> make the databases consistent.
>
> If anyone cares, the nested "for" loops are as close to real
> cross database operations as we went, because the next step is
> a big one.

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???

>
> > > >2) The UDF processing has no associated transaction context.
> > >
> > > As above - a serious problem when trying to access back into the
> > > current database, but irrelevant for foreign database access.
> >
> >I'm not sure how you are thinking, but to me this looks like a
> distributed
> >transaction is happening. ... I assume
> >the UDF would be able to do updates as well as queries.
>
> That is so far beyond the scope of current UDF's that I never even
> considered it. UDF's are not the way to establish cross-database
> statements.

I agree, I just don't see any way to get accurate answers without
distributed transactions.
>
> >By the way, how does firebird do 2pc now? Is it documented reasonably
> well?
> >(I know, RTFM, but which one?)
>
> As above. The operations guide has a tiny bit about recovering
> limbo transactions. The whole mechanism was basically abandoned
> because the BDE was supposed to handle all cross-database issues.

Are you telling us that Borland abandoned a multiplatform distributed
transaction manager in favor of the BDE?????????????????
>
>
> Regards,
>
> Ann
> www.ibphoenix.com
> We have answers.
>
>
> To unsubscribe from this group, send an email to:
> IB-Architect-unsubscribe@onelist.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>