> It seems that I will be remembered as the south American guy that used to
> rant against SQL VIEW's.

I agree the syntax for the VIEW definition is the best place to formalize
what should be taking place.

Another way this could be approached is to make it so that you have to
explicitly turn on the default view update processing. It would just raise
an exception if you tell it to do something and then it doesn't know how to
do it. Thus, by using these tokens, you merely tell it to put the triggers
on it for you. Other triggers you might still add would just be for other
purposes.

CREATE VIEW blah
FOR UPDATE, INSERT, DELETE
AS
BEGIN
....

Then, in general, the view would allow DML for whatever events there are
before triggers defined for. If someone tries to prepare an update statement
against a view and there are no before update triggers assigned for it, an
exception should be raised.

So, either you use a token in the view creation to get an internally defined
default update trigger or you make your own and then the view allows
updates.

If someone's VIEW is a JOIN and they try to put tokens in the view create
statement it will raise an exception that it doesn't know how to make it
updateable and so then they will have to just add their own trigger to the
view in order for it to be made updateable.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com