Subject | RE: [IBO] TIB_Query and InsertSQL |
---|---|
Author | Helen Borrie |
Post date | 2007-04-10T22:08:38Z |
At 12:40 AM 11/04/2007, you wrote:
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...
Helen
> >----*/Hmmmm. Can you make a small demo app using the employee database?
>
>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.
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...
Helen