Hellen,

First of all thank you for the quick reply and for confirming my guess
as to te cause of the problem.

> Correct. IBO reads the RowsAffected count from the structure that
> is returned from the execution of the DML statement. It uses this
> number to determine whether the Insert statement it passed across
> the wire had the logically proper effect of inserting one and only
> one row to the dataset's underlying table.

IMHO the assumption that only a single row is the only "logically
proper effect of inserting" is a bit too strong. After all triggers
are a standard feature of both FB/IB.

Maybe a property should be added (at the dataset level? transaction?
connection?) to instruct IBO to relax this assumption.

>> Is there any way to tell IBO to allow more than 1 row per insert?
>> Maybe another workaround?

> No, but no workaround is necessary! As the programmer, you know
> that this particular Insert call is going to cause this condition
> when the Insert operation executes the DML --- and you know that
> it's OK. To you, this particular exception is merely an alert that
> confirms that your Insert operation had the desired effect. So
> just handle that particular exception and swallow it. (If you
> don't, of course IBO has no way get past the exception condition
> other than to raise it and stop the show!!)

I'm not sure how an exception handler can solve the problem. After
exception handling control is returned to the statement that follows
the TRY/EXCEPT block. In other words IBO's code after RAISE staement
never gets executed. So swallowing the exception can prevent the error
message but won't ensure propert execution of the Post process.

Despite the above I did follow your advice to swallow the exception.
However, although there's no longer an error message, the transaction
remains open and the new data is invisible, until I exit
the application.

This is probably because the code that takes care of propely commiting
the transaction is after the RAISE statement and so doesn't get to do
its job.

I tried to call the dataset's Commit in the handler, but that only
resulted in a duplicate insert (which also was only visible after
exiting the application). I also tried to call the transaction's
Commit, but that only resulted in another exception (token unknown
"where").

One more thing I tried is provide OnError event handler and set
RaiseException to FALSE, but the handler doesn't even get called.

Any other ideas?

Thanks,

Eyal.