From: "Paul Schmidt" <paul@...>

>
> If the database is designed properly, then this isn't really a problem, in

fact it means

> fewer problems, one of the problems with having separate databases all

over the

> place is keeping them synchronized, users (and system operators) can't

always

> grasp the idea that when you restore DatabaseA (3MB) that you always need

to

> restore DatabaseB (17.5GB) as well, so 95% of the time, they don't and

then you

> end up spending two weeks trying to put the pieces back together (been

there, done

> that).
>

Still, there are situations where more than one database is called for. For
instance, in my main app, information is archived for the current year, and
each year it is archived to a history for that fiscal year. That means a
database for the current information, a database for the current archive,
and a database for each fiscal archive. Doing reports across multiple fiscal
years means separate queries for each database. Fortunately, I've already
developed a class component which lets me use multiple databases and queries
easily but it would be much easier to write a stored procedure to return the
result set instead of working with more than one.

Temp tables I have no use for at this time.

Woody (TMW)