>----*/

That is unique_key_violation. Your mistake here
is due to your handling of the primary key for
the new record. Because there is no underlying
table to the dataset, you cannot use a parameter
for inserting it via a DSQL statement. (This
should not have worked previously....I think
there is some other change you haven't mentioned...)

I am using the GeneratorLinks from the TIBO_Query and it is correctly
fetching the primary key from the generator when the Insert is done.

GeneratorLinks

MaintenanceItemNumber=MaintenanceItemNumber

There might be some other change but as far as I can tell it is only the
version of IBO. I will put a before insert trigger on the underlying table
and remove the primary key field from the input SQL. That just might work
but from what I know (and it probably is what I don't know that will
eventually make sense of this) I think the new version of IBO probably
should be able to handle this. It calls my BeforePost event handler and all
the new insert data is there along with the primary key that was fetched
from the generator when it was put into the insert state. It is after this
point the post fails and the values it is trying to post are from a
different row, specifically the last row selected before insert was called.



I have made the changes - I am using a trigger to get the next primary key
if the new key passed is null. I removed the Primary Key from the Insert
SQL. Now the row posts with a new primary key but all the rest of the data
is from the last row selected before the insert. None of my new insert data
was put into the row. The monitor also continues to cause an access
violation.



In a well-ordered world, you would have a
generator for the primary key and a Before Insert
trigger populating it. In this case you *can*
use a DSQL INSERT statement for your InsertSQL
and omit the primary key from the insert
statement entirely. Alternatively, you could use
GeneratorLinks and have IBO fetch the value automatically at BeforeInsert.

If you are creating the PK by some other means,
you still have a couple of alternatives.

-- If you are doing it client side (NOT
RECOMMENDED!!) then do so, and apply it, in the
dataset's BeforeInsert handler.

-- If you have some different, server-side
mechanism for creating the primary key value then
you must write a stored procedure to do the
insert, with an input parameter set that is
sufficient to pick up the needed values from the
current Fields[] array of the dataset but NOT the
primary key. Your InsertSQL would then be an
EXECUTE PROCEDURE (:param1, :param2, :etc...)
statement, making sure that you match the
parameter placeholder names with the
corresponding identifiers in the output set.

Helen

[Non-text portions of this message have been removed]





[Non-text portions of this message have been removed]