Subject | Re: [IBO] KeyLinks |
---|---|
Author | Helen Borrie |
Post date | 2004-05-02T21:47:35Z |
At 05:23 PM 2/05/2004 -0400, you wrote:
targeting one and only one row for updates and deletes. For searching, the
WHERE clause is used.
On single-table queries, if the primary key is in the dataset and you set
KeyLinksAutoDefine, IBO will try to determine the KeyLinks itself. For
joins, unions, or for datasets that don't include the PK, or that include
only part of it, or views that don't have logical keys, you must set
KeyLinks and ensure that they define a unique row.
If worst comes to worst, IBO will use the RDB$DB_KEY for KeyLinks. In an
unkeyed dataset, IBO actually fetches it as part of the row data - you will
see a column named DB_KEY. The value of db_key doesn't reliably survive a
commit, though; and it must be excluded from inserts, since new rows don't
have a db_key.
Helen
>Is it necessary to specify keylinks if a query uses a primary key to findDatasets need KeyLinks for a lot of things. One of the "things" is for
>a record?
>I use and reuse utility queries in this way.
targeting one and only one row for updates and deletes. For searching, the
WHERE clause is used.
On single-table queries, if the primary key is in the dataset and you set
KeyLinksAutoDefine, IBO will try to determine the KeyLinks itself. For
joins, unions, or for datasets that don't include the PK, or that include
only part of it, or views that don't have logical keys, you must set
KeyLinks and ensure that they define a unique row.
If worst comes to worst, IBO will use the RDB$DB_KEY for KeyLinks. In an
unkeyed dataset, IBO actually fetches it as part of the row data - you will
see a column named DB_KEY. The value of db_key doesn't reliably survive a
commit, though; and it must be excluded from inserts, since new rows don't
have a db_key.
Helen