Progress
Programming
Handbook
ROWID and RECID Data Types
Progress provides two structure types to support record fetches. One structure type, the index, you define in the schema of your database. The other structure type, a results list, is temporary; Progress builds it at run time. The results list associated with a DO, REPEAT, or OPEN QUERY statement with the PRESELECT option is sometimes called a preselect list.
In addition, there are two data types, ROWID and RECID, that allow you to retrieve a pointer to a fetched record. You can use this pointer to:
In addition to the examples in this section, you can see ROWID at work in the chapters that describe the following Progress features:
- Browse interactions — Using the Browse Widget."
- Transactions and updates — Transactions."
- General lock management — Locks."
ROWID versus RECID
ROWID is supported by all DataServers. Earlier Progress versions provide RECID as the only way to fetch a record pointer (supported in this version for backward compatibility). RECID is limited to a 4-byte record address supported by only a few DataServers and standard Progress. ROWID provides a variable byte string that can represent a record address for any type of DataServer. For DataServers that use the 4-byte address supported by RECID (including Progress), ROWID also uses a four-4 value. Thus, there is no loss in performance using the more portable ROWID instead of RECID.
Returning Record ROWID Values
Progress provides a function named after the ROWID data type to return ROWID values. Given a buffer name, the ROWID function returns the ROWID of the current record in the buffer. This example fetches the first customer record, and if it has a balance, refetches it to lock it for update:
Storing and Retrieving ROWID and RECID Values
As shown in the previous example, you can store ROWID values in ROWID variables. You can also store them in work table fields. Thus, the following are valid ROWID storage definitions:
You cannot store ROWID values in database or temporary tables, but you can store their hexadecimal string representations using the STRING function. You can then retrieve the string as a ROWID value using the TO–ROWID function:
You can store RECID values directly in a database or temporary table.
Additional 4GL Support
Several additional statements use ROWID and RECID values directly. For example, the REPOSITION statement sets the query position to a record given by its ROWID or RECID. For more information, see the "Results Lists" section.
Also, because RECID is not supported by all DataServers, Progress provides the DBRESTRICTIONS function to indicate whether a particular DataServer supports it.
Converting from RECID to ROWID
When changing an application to use ROWID that currently uses RECID, you can complete the change with only a keyword substitution if your application:
Otherwise, after you change all “RECID” references to “ROWID”, you must rewrite your integer references to use character strings. If you use database or temporary tables, you must also convert the relevant fields to CHARACTER fields, and use the STRING and TO–ROWID functions to store and retrieve ROWID values. However, note that some DataServers build a string for a single ROWID that can reach up to several hundred bytes (including a complete WHERE clause).
All DataServer tables support ROWID references except those, such as views, that do not have unique row identifiers. DataServers from earlier Progress versions also support ROWID references. Versions 7.3A and later use an internal RECID that transparently converts to a ROWID in the client.
Writing DataServer-portable Applications
The least portable feature of ROWID references is the scope of a ROWID reference and when it changes for each DataServer. To maximize portability, follow these rules:
- Always assign values to unique keys before returning the ROWID value of a record. Some DataServers use a unique key to generate the ROWID value.
- If you UNDO a DELETE of a record for which you have stored the ROWID value, return the ROWID value again after the UNDO. It might be different after the record is recreated.
- If you update a unique key value for a record, return its ROWID again to replace any prior value.
- Never expect a record to have the same ROWID value between sessions.
Note that each DataServer uses a different method to generate a ROWID for a table, and sometimes for different tables in the same database. Therefore, never expect ROWID values to be identical, or even compatible, between otherwise duplicate tables from different DataServers.
For more information on ROWID value construction and scope for your DataServer, see your Progress DataServer guide.
Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |