Consultor Eletrônico

Status: Unverified

GOAL:

How to handle Temp-Table Field Ordering with Open Clients

FACT(s) (Environment):

OpenEdge 10.0A

FIX:

Each field in a Progress Temp-Table, as in any database table, has an
_rpos value and an _order value. The _rpos value generally corresponds
to the physical order of the field. Whereas, _order corresponds to the
"user" order, i.e., the order in which the user wants to see the
fields. Therefore, most statements in Progress (such as DISPLAY) show
fields in _order order.

However, when a Temp-Table is sent as an OUTPUT parameter from a
procedure running on the AppServer to an Open Client, the contents of
the table are sent in _rpos order, not in _order order. Thus, the Open
Client may see the fields arrive in a different order than seen by the
4GL. As an example, the sports database Customer table Address field
appears as the 4th field in the 4GL, but may appear as the 3rd column in
a Java ResultSet.

This inconsistency has further repercussions with the introduction of
TABLE-HANDLE parameters (Dynamic Temp-Tables) for Open Clients. If the
_order and _rpos are different, and a given table is passed from the
server as OUTPUT, then returned to the server as INPUT, field indices
for that table will be different on OUTPUT than they are for that same
table on INPUT in 4GL server-side procedures. Note that this only
occurs with Open Clients because 4GL clients receive more ordering
information than is available to Open Clients.

The _rpos order and the _order may or may not be the same according to
the following rules:

· If the Temp-Table is not based on a database table, the two orders are
always the same.

· If the Temp-Table is based on a database table by using LIKE (static
tables) or CREATE-LIKE (dynamic tables), then the Temp-Table inherits
both the _rpos and the _order values for each field. Therefore, the
ordering will be the same only if that is true for the database table.
The Customer table is an example of where they are different.

· If the Temp-Table is based on a database table by using
ADD-FIELDS-FROM then the fields will be added in _order order and the
_rpos values will not be inherited but will be created in sequence, thus
producing the same field ordering.

· If the Temp-Table is based on a database table by listing/adding all
of the fields individually (e.g., by using "FIELD <name> LIKE for a
static table or ADD-LIKE-FIELD for a dynamic table"), this is equivalent
to the first bullet. In other words, the _rpos and the _order order
will be the same. This is how the AppBuilder generates Temp-Table
definitions that are based on a database table.

In summary, the only way that the two orderings will be different is by
using LIKE or CREATE-LIKE. Therefore one way to prevent this problem is
by using one of the other methods of defining the Temp-Table other than
using LIKE or CREATE-LIKE.

Another possible workaround is to use field names instead of numerical
indices to access columns/fields on both client and server. For most
applications the use of field names is a more robust and maintainable
coding practice. The Progress Open Client API and the Progress 4GL both
support accessing fields by field name.

4GL Example:

fh = bh:BUFFER-FIELD( "Address" ). <--- Do this.
fh = bh:BUFFER-FIELD( 4 ). <--- Don't do this.

Java Example:

fieldValue = getObject( "Address" ); <--- Do this.
fieldValue = getObject( 3 ); <--- Don't do this.