Subject | Re: [IBO] Record was not located to update |
---|---|
Author | Helen Borrie |
Post date | 2003-12-08T06:48:57Z |
At 10:17 AM 8/12/2003 +0800, you wrote:
rows don't have a db_key and they won't get one until after the posted
insert is committed and the query is run afresh. It's a really bad idea to
rely on db_key for a table that you have to insert to. Even if the table
doesn't have a PK (which sounds pretty silly to me), you should supply all
of the table columns that make a row unique into the KeyLinks property.
If the detail set is a joined set, you still need to establish
uniqueness. An update (or delete) has to target one and only one row
precisely with a WHERE condition that is capable of finding that one row.
In addition, if you have an application design that is trying to update
rows that have been inserted but not committed, then you need to examine
your design. If the only way you can see an inserted row is to shut down
the connection, then that's a clear indication that the design is wrong.
Helen
>Hi guys please help me with this.The db_key is created by the engine when you SELECT a set. Newly-inserted
>
>I have a tib_query(a detail dataset) that has a problem of not being
>able to update a record. I dont have primary key for this table. So I
>set the autokeylinks to true to use the DB_KEY as its keylinks. I even
>check the master detail setup everything is correct. This problem happen
>before, and I forgot how did I solve it ... I think I drop the component
>and create a new one, but this time it didn't work.
>
>But when the application is close and open again I can now update it.
>When when it is newly inserted and it was post and commit I cannot
>update it until I close and reopen the application.
>
>I dont know if this has to do with my problem. But the setup is this
>.... I have a two detail dataset the other one works fine ... it has the
>same setup up with the one that has problem...
rows don't have a db_key and they won't get one until after the posted
insert is committed and the query is run afresh. It's a really bad idea to
rely on db_key for a table that you have to insert to. Even if the table
doesn't have a PK (which sounds pretty silly to me), you should supply all
of the table columns that make a row unique into the KeyLinks property.
If the detail set is a joined set, you still need to establish
uniqueness. An update (or delete) has to target one and only one row
precisely with a WHERE condition that is capable of finding that one row.
In addition, if you have an application design that is trying to update
rows that have been inserted but not committed, then you need to examine
your design. If the only way you can see an inserted row is to shut down
the connection, then that's a clear indication that the design is wrong.
Helen