At 14.13 27/11/2001 -0700, you wrote:

>Marco,
>
>Ann Harrison and I have got a pretty clear picture in view. I think we will
>be able to come up with a solution which will work quite well. What I have
>communicated and what I think will work very well (which is largely what you
>suggested) is as follows:
>
>RowsAffected is what we are after but with views we need to think of it as
>"rows operated upon" instead. In other words, when doing an update, we don't
>care how the view trigger(s) implemented the actual updating of the view
>record(s) but rather how many rows of the view were operated upon during the
>update (or delete for that matter). With insert it is always just one.
>
>This would rest upon an assumption which would need to be clearly
>documented. Whenever making triggers on a view it is important that they
>only affect the actual row of the view in the appropriate way expected. If
>for whatever reason the triggers could not accomplish the desired affect
>upon the view there should be an exception raised. If the triggers are wrong
>and don't accomplish this then the fault be the programmers for breaking the
>(what should be) rules.
>
>Then, with this in place as such, we will have a system which delivers a
>clear, consistent and uniform behavior for the RowsAffected property for
>both tables and views. It puts the burden where it belongs and that is upon
>the developer to properly implement the action in triggers on the view or
>responsibility raise an exception when it fails to.
>
>I believe this should be very straight forward to implement in the Firebird
>code since RowsAffected for just plain tables is also the "rows operated
>upon". Thus, it should be the same code and there is no need for it to
>quantify the actual physical activities of the triggers to implement the
>update to the view. Such is already the case with plain tables, why should
>views be any different other than you are responsible to carry out the full
>implementation of the updates.

OK, so I suppose the rowsaffected parameter will be 1 for both
insertions and updates on the trigger.
I think that it is right to leave to the programmer the responsibility of
writing right triggers on views as usually views aren't updatables
so the single programmer will do with triggers what he wants.
If he need to update for instance 5 records in background it's is choice
but in the view the update will appear only on the row on which it is
applied.

>I hope this restores some measure of confidence to this whole ordeal. And, I
>really hope this is how it will be implemented because to me it appears as a
>win-win-win situation for all involved. It also makes it totally unnecessary
>to implement my -1 hack, which in retrospect was a horrible idea.

I think that as 1 was my idea (at the beginning it wasn't a reasoned idea,
instead
was an hack of my own) -1 was yours,
this is a new unexplorated world, we have to explore and exploit it!

>Marco, this is the way things are always going to appear at the "coal face".
>(This is the part of a coal mine where the workers are struggling and
>digging new territory under the earth. It is a very volatile and precarious
>place to be.) With open source, many people are introduced to the "coal
>face" and it rattles them a bit. You will get used to it, as do many of the
>coal miners. (I lived for two years in a mining town.)

OK!


Regards
Marco Lauria