Hi Helen,

> Going back to the principle at issue here, I urge you to
> reconsider your design with regard to maintaining this computed
> column. It's not the first time I have seen unpredictable results
> from computed columns having dependencies on other tables.
> Firebird SQL has much more robust alternatives.
>
> I won't store summary values as computed columns. Even in regular
> columns I won't do it unless it is absolutely unavoidable (and, yes,
> there are still some disgustingly awful reporting packages out there
> that can't handle aggregations...for these I would still prefer to
> make a view or a SP to generate the output sets, in preference to
> storing summary data...).
>
> Earlier this week I was watching a thread where someone was
> struggling to use computed columns with other-table dependencies as
> a way to denormalise his entire database - trying to make a Firebird
> database into a bunch of spreadsheets. He was strongly advised by
> several people to reconsider this design strategy, but it seems he's
> really serious about it! He actually put in a feature request to
> have gbak "fixed" to enable him to make such a monstrosity
> restorable.
>
> Keep your stored data abstract. Don't fear joins and correlated
> subqueries. They are the arteries of a well-designed RDBMS.

Hmmm... I guess I have to re-design my table definitions. Thanks
for your reply. :)

By the way, in relation to this, is it safe to do queries like:

SELECT
X.*,
(SELECT SUM(AMOUNT)
FROM Y
WHERE CODE = X.CODE) AS TOTALAMOUNT
FROM
X

Thanks Helen:)

Joeny