> 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.

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?

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.

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).

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.

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