Kbase P116250: Should I use the LIKE option for parameter temp-table definitions?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
22/05/2006 |
|
Status: Unverified
GOAL:
Should I use the LIKE option for parameter temp-table definitions?
GOAL:
Does defining a temp-table LIKE a Database table match the _Order list of fields?
GOAL:
Is defining temp-tables LIKE Database tables a good approach for parameter passing?
FIX:
Using LIKE and hoping it will match the _Order list of fields is an extremely bad idea.
When defining a temp-table LIKE a Database table, Progress tries to order the fields in the _Field-Rpos order of the Database table. However, if there are holes in the Database table's _Field-Rpos, Progress gives up and orders them by the table's _Order order because temp-table tables cannot tolerate holes in the _Field-Rpos. A hole is a break in the sequence; for example, a particular table has fields with _Field-Rpos values such as: 2, 3, 4, 6, 7. This may have come about because the table was created with six fields and the fourth field (at _Field-Rpos 5) was subsequently deleted.
The reason for using the _Field-Rpos order is to support RAW-TRANSFER ? so that the temp-table record and the database record would have the same format. This works very badly for parameter passing, unless both sides are defined with LIKE on THE SAME database, or one side is not defined on _Order, but on _Field-Rpos. The _Field-Rpos is very unreliable ? during dump and reload there is a check-box about whether to retain it or not, and it can easily be lost, causing the temp-table parameters to go out of synch again.
Therefore, the recommended way to fix the problem is to NOT use LIKE for parameter temp-table definitions. The other problem with LIKE is that one cannot compile code against the temp-table on a disconnected client.