On Tuesday 12 February 2008 03:25, Bryce Nesbitt wrote:
> Yes, the view approach has some advantages. But it still leaves the
> underlying tables naked to modification. And since the most likely
> error is... well... me (or another admin) at the SQL prompt, we want
> underlying tables protected
On Tuesday 12 February 2008 03:25, Bryce Nesbitt wrote:
> Yes, the view approach has some advantages. But it still leaves the
> underlying tables naked to modification.
> And since the most likely error is... well... me (or another admin) at
> the SQL prompt, we want underlying tables protected al
(because our legacy application, which won't change, is using the
underlying tables. We can't do step #5).
Bryce Nesbitt wrote:
Yes, the view approach has some advantages. But it still leaves the
underlying tables naked to modification.
And since the most likely error is... well... me (or
Yes, the view approach has some advantages. But it still leaves the
underlying tables naked to modification.
And since the most likely error is... well... me (or another admin) at
the SQL prompt, we want underlying tables protected also.
chester c young wrote:
> instead of triggers I use update-a
> I'm considering building a protective mechanism, and am seeking
> feedback
> on the idea. The approach would be to add a new column named "ro" to
> each table at invoice level and below. Then have a trigger on
> 'ro'==true deny the write, and probably raise a huge stink. As
> invoice
> are ma
I've got a largish database which once a month churns out some
invoices. Once those invoices are created, there is zero business logic
reason to ever modify the underlying data. A few hundred thousand
database rows go into the building of each month's invoices. New data
is added all the time, an
