At 12:40 AM 11/04/2007, you wrote:

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

Hmmmm. Can you make a small demo app using the employee database?



I have yet to be successful in doing that as yet but will continue trying.
I suspect when I am successful duplicating the problem the solution might be
obvious.


As a further measure, it would be a good idea to get hold of the
v.1.5.4 client dll. The v.1.5.2 client has a variety of known bugs,
some of which cause AVs. It's not beyond the realms of possibility
that the latter-day changes in IBO have brought one of these bugs to
the surface...on that subject, literally hundreds of bugs were fixed
in the *two* sub-releases of Fb 1.5 since Dec. 2004 when v.1.5.2 was
released...



Already done that. The newer version of IBO fails on both versions of
Firebird (1.5.2 and 1.5.4) and the older version of IBO works on both.

I thank you for your input Helen. I really think this is an IBO problem but
then again I have thought that before and have been wrong.


Helen



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