At 10.57 26/11/2001 -0700, you wrote:

> > I am getting crazy, as I haven't encountered the problems with multiple
>updates
> > that affected IB....
> > and now instead I have big troubles for this new "fix" that Claudio
>introduced.
> > I think that the right think should to return 1 for both insertion and
> > updates...
>
>You need to take a step back and look at the issue you are dealing with. I'm
>not one to toss in a cheap hack to solve a problem. I'd like to see a real
>solution to this mess but this is going to involve a lot of work to do
>right.

Jason, I agree with you, but as a "cheap hack" is begin inserted in the engine
for the Firebird 1.0 release, I think that the better hack can be returning a 1
instead of a zero.
returning one has a logic, returning zero has no logic.

>Because updates to views are handled in triggers it is really not possible
>to deliver an exact RowsAffected figure without it being a very complex
>thing. Why complex? Well, people could actually do updates, inserts and
>deletes for any operation being carried out. A DELETE from the view could
>actually be implemented as an UPDATE to a record. In this case, how is the
>RowsAfected dealt with?

If we have to treat the views as tables the only solution is to return 1,
in other cases every tool like IBO will not know how to deal with views...
as views inserted in select statements works as selects, returning
one rows affected for every operation will be transparent for clients
checking the parameter.

>What I would like to see is for stored procedures to have the ability to set
>the values that will be returned as the RowsAffected and to get the
>RowsAffected from statements inside of the stored procedure being executed.
>In this way we can produce code on the server that accurately defines what
>all has been affected. Something similar would be implemented for VIEW
>triggers as well.

This is the real solution, but as I am telling you before,
returning zero is an hack that don't work on IBO as it is completely
out of logic, a trigger will do something that is a group of operation,
but does something on the database
so the row of the "view" will be affected....
I am interpreting rows affected from a "view" point-of-view and not from
a "database" point-of-view

>But, this is part of software development. We are in the gray area where
>things become difficult and a bit ambiguous. This is why you get paid the
>big bucks is to get your job done in spite of these frustrating areas. <g>
>If it were super easy, anyone could do it and us programmers would be a
>"dime a dozen" (that means really cheap).

THis is normal.

>So, you have two choices, use stored procedures (which IBO ignores the
>RowsAffected on because they don't have them) or make some modifications in
>IBO to ignore the RowsAffected on views. Either option will get the job
>done.

Or the first solution...
Regards
Marco
P.S. do you have a flag on the DSQL statement after prepared that tells
if you are working against a table or a view?