Hi Guys,

I have been a little busy lately so I have not been able to be very
helpful lately, but this thread just caught my attention and I have to
speak up about it.

One of the most common problems discussed a year or so ago, was not
being able to drop a [insert choice = procedure, trigger] because it
called another object that was renamed/droped previous to this. This
was caused by the engine wanting to recompile the object before dropping
it (seems weird to me, but well, you know....).

This caused some very bad dependancy trees within a single database
where things happened to change across versions. Now we are discussing
a further level of dependancies across databases or even across database
servers.

Although I greatly appreciate the need for the ability(it would knock
alot of code and redundancy out of our design models), I would be very
hesitant to use it unless it had standard ON ERROR XXXX event
handling. The ability to perform conections to other databases would
be wonderfull, but the server code that compiles the blr, must not freak
out if the remote database is not there, maybe just record it in the log
and carry on. If a view/procedure/trigger depends on a remote database,
and that database is not available, a simple error message (that can be
handled via the on error block with the procedure language) should be
issued.
I do not think that the metadata compiler should even check for the
presence of the remote database during metadata operations. It should
do what the developer tells it and let the developer deal with the mess
if they screw up.

just my 2c

best regards

Dalton

Olivier Mascia wrote:

>
> > Even if we go to the third model, cross-database constraints (and
> > procedures, and triggers) is a problem that merits much discussion.
> > How do we handle the case of access to one database when the other
> > is not available? What happens if one database is moved or renamed?
> > Yes, aliases help here, but I'm so used to the idea that a database
> > is a single entity that putting permanent links between databases
> > really bothers me.
>
> I could not agree more on anything on earth than on this !
>
> When someone comes to the point where such cross-database access is required
> it just means the problem is ill-defined. Those multiple databases should
> have been combined in a single DB ! Let me push the idea to its (stupid)
> limit : let's offer a full third-model cross-database model, add a
> restriction of one table per database (as you would have cross-triggers,
> cross-constraints and the like you do not need anymore suport for multiple
> tables in a DB, as you have all the facilities cross-DB), and call this
> 'dBase3000'. Should be a best-seller. :-)
>
> Today InterBase/FireBird offers a very nice cross-database access from the
> client side, through transactions (on the server side) which can span
> multiple database connections. I will personally always vote that this is
> well architectured, simple, usefull and enough for the occasionnal cases
> where a cross-database workflow should occur.
>
> ____________________________________
> Olivier Mascia, om@...
> T.I.P. Group S.A., www.tipgroup.com
>
> We may not always have answers,
> though we're seldom short of ideas ;-)
>
> ----- Original Message -----
> From: "Ann W. Harrison" <aharrison@...>
> To: <IB-Architect@yahoogroups.com>
> Sent: Wednesday, March 07, 2001 1:01 AM
> Subject: Re: [IB-Architect] Proxy Query ?
>
> > At 12:49 AM 3/7/2001 +0100, Darko Prenosil wrote:
> >
> > >I got only few more question :
> > > How high on the Firebird to do list is this subject ? (Unfortunately
> I'm
> > >not programmer good enough to do it my self.).
> >
> > Cross database access in SQL is an important feature, but also a
> > major effort. First, we'll need to agree on language extensions
> > and direction. One alternative is to allow access to several
> > databases but restrict any specific query to one database. Another
> > is to allow databases to be mixed in a query, but keep each select
> > expression restricted to one database. The best, and hardest, is
> > to allow free reference to multiple databases.
> >
> > The hard part ... well, there are several ... but the hardest part
> > is cross database optimization. We have a lot of work to do on
> > the single database optimization - and the complaints there demonstrate
> > how painful bad optimization is. For that reason, I would tend to
> > make the first implementation follow the first or second model.
> >
> > Even if we go to the third model, cross-database constraints (and
> > procedures, and triggers) is a problem that merits much discussion.
> > How do we handle the case of access to one database when the other
> > is not available? What happens if one database is moved or renamed?
> > Yes, aliases help here, but I'm so used to the idea that a database
> > is a single entity that putting permanent links between databases
> > really bothers me.
> >
> > 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/