Todd:

I agree with you. There are some appl that could benefit from both
situations.

What I don't agree is that this 2 things will keep 'corp developers' away
from using Firebird.

As you can see in 'Open Features' request:

-------------
451924 Temporary tables Feature request
Allow for the definition of temporary tables which are only visible within
the current connection context and which are deleted upon connection
disconnect/lost.
-------------
446244 Multi-database access in triggers and SP Feature request
Allow for other databases to be accessed from within triggers and SPs.
---------------

Personally, I think that feature request 451912, 446233, 446232 just to
mention a few ones, are more important than the 2 features in discussion
here. What I think we are discussing here it's not if a feature it's good or
not, but priorities to implement that features in Firebird.

Artur

----- Original Message -----
From: "Todd Brasseur" <todd.compass@...>
To: <ib-support@yahoogroups.com>
Sent: Monday, June 10, 2002 4:57 PM
Subject: Re: [ib-support] Two things Firebird needs for corp acceptance


>
>
> Artur Anjos wrote:
>
> > Tony,
> >
> > I will complete Martjin questions with this one:
> >
> > - Why you are joining 'corp developer' with 'corp client'?
> >
> > As Martjin, I don't know what's the problem to have lots of tables in
the
> > same DB.
>
>
> I would like to be able to join databases as well. We have an
> application that stores alot of data that changes all the time. It also
> stores alot of images which hardly ever change. We split up the
> database into 2 separate databases for a few reasons:
>
> 1) The images are huge (several gigabytes). They only need to be
> backed up once a month or so.
> 2) The user likes to make local copies of the database to do analysis.
> It makes it alot easier to only have to backup and restore 150 megs
> rather than 10 gigs.
>
>
> Also, we are trying to integrate with some other data that isn't part of
> our application. With SQL Server our clients can add triggers, etc.
> that do things between databases. We can't do that.
>
> > You can do almost all things that you want in a SP without using a
> > temporary
> > table. Also, it's very easy to emulate a temporary table with a table
> > and an
> > ID, in most part of the jobs you need a temp table to.
>
> Temporary tables would be great for complex calculations. We select a
> ton of data and then need to calculate math on the data. It would be
> nice to store the results of one query either in an array or a temporary
> table and then be able to calculate standard deviations, medians etc.
>
> Todd
>