At 06.11 26/11/2001 -0400, you wrote:

>In a few words: fix IBO. The current check is fine with tables. The check
>doesn't and won't work with views in more than the simplest case, since
>their triggers can do anything unrelated to the original operation. Only the
>developer knows what he/she did with his/her views. I only stopped the
>server from counting fake operations that weren't happening as real I/O
>operations over records (and so, avoid "inflating" the number of records
>inserted, deleted or modified that are returned from the API). Furthermore,
>remember that IBO doesn't detect mandatory fields in views: you should set
>the REQUIRED flag yourself. It's nearly impossible (almost senseless) to ask
>a client-side package for the detection of mandatory fields in views
>automatically, BTW. Here's the original bug fix for "Rows affected incorrect
>with trigger":
>
>http://sourceforge.net/tracker/index.php?func=detail&aid=436462&group_id=902
>8&atid=109028
>You should know that triggers never have been counted among the I/O
>operations returned. I didn't change that. I only put a check to ensure the
>counters are updated only when EXT_store or VIO_store are called for
>insertions (and the equivalent for deletions and updates), for external
>tables or records in the db, respectively.
>
>Unless you integrate IBO and FB in a monolithic construction and so offer a
>direct competition of Access (db + GUI) or encapsulate the whole engine into
>IBO classes and make IBO a competitor for DataSnap (MIDAS) and
>client-datasets, the problem of detecting exactly how many operations
>happened on a view is a superflous point. That number can't be used to tell
>whether a client-side operation was successful or not with a view. I know
>IBO does that to guarantee that by mistake people do not step into more than
>one row and mangle data. For example, missing the PK to identify a record,
>so you delete more than one row because you aren't using a combination of
>columns that make the field uniquely identifiable (and this happens with
>views because they don't have a real PK if you don't select meaningful key
>columns). But again, the check's only valid with tables, not views. Hope
>Jason will see the point here. It's impossible to please everybody.

Infact that was what I was thinking about,
simply the solution is fixing IBO so that it will ignore rowsaffected if the
destination table is a view.....

>And about automatically updatable views as they work currently in the
>engine, I could say a couple of technical things, but rests to say to I
>consider them the equivalent of having an unexpected meeeting with the
>Gestapo at 3 AM while trying to escape from the KGB and eluding the CIA that
>wants you, too but taking care that the maffia doesn't get wind of you
>before the secret policies. A real nightmare.

I use them as I wrote to manage an hierarchy of tables
I have this structure:

TABLE DOCUMENT(
PK, GENERICFIELD1, GENERICFIELD2, GENERICFIELD3)

TABLE DET_DOCUMENT_A(
PK, SPECIFICFIELD1, SPECIFICFIELD2, ...)

I use a view
CREATE VIEW V_DET_DOCUMENT AS
SELECT D.PK, D.GENERICFIELD1,....,
DET.SPECIFICFIELD1,DET.SPECIFICFIELD2

to manage the specific documents
and I make this views updatable....

now I have almost a generic document header and 7 detail tables....
and I also use this work schema for the rows-tables of the documents....

I prefer to do this as it is simpler for my co-workers to manage
the data in the views instead of having to deal with a lot of joins....
also I think that using triggers on views is more powerful than
using stored procedures for updating the tables.

But I think this is my opinion ;)

I trust you, knowing that you are a very good programmer, when you say
that from the engine - point of view - updatable views are a nightmare...
but for me are really useful.

Regards
Marco