Well, after almost 2 weeks of pulling my hair out on the select stored
procedure / InsertSQL problem I at least know what will make the problem go
away (sort of).

I had a varchar field of 1024 chars that when I reduced it to varchar(971)
or less the problem disappeared. Maybe that size has something to do with
blobs and will trigger something with Jason. The strange part is, with the
exact same code, the exact same database with the only change begin IBO 4.6
vs IBO 4.7.16, IBO 4.7.16 always works with 971 or less and IBO 4.6 always
works with 972 or more. I cut the size down all the way to 16 and IBO 4.6
would not work. So I am thinking there is some kind of database corruption
causing the problem. I have backed up and restored the database many times
and that does not seem to help at all.

So I guess I rebuild the database from scratch and re-load.

Any other ideas?

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