For TABLE parameters, the proxy calls the next() and getObject() methods to get the data that needs to be passed to the application server methods. For a TABLE-HANDLE parameter, the proxy must first obtain a ResultSetMetaData object by calling the getMetaData() method in order to determine the format of the data.

There are several alternatives for how getMetaData() can supply the appropriate ResultSetMetaData object:

  • Use a standard JDBC ResultSet if:
    • The input ResultSet is a standard JDBC ResultSet obtained from a query, and the client application does not need to do anything
    • The ResultSet instance already implements the getMetaData() method and returns a standard ResultSetMetaData object.

    The proxy automatically maps SQL data types to ABL schema data types, as shown in the following table.

    Note: Because a standard ResultSet supports a standard ResultSetMetaData object and not the ABL extension (ProResultSetMetaData), there can be no array fields.
    Table 1. Mapping between SQL and ABL schema data types for standard JDBC ResultSet
    SQL type ABL type
    BIGINT INT64
    BIT LOGICAL
    BLOB BLOB
    CLOB CLOB
    DATE DATE
    DECIMAL DECIMAL
    INTEGER INTEGER
    LONGVARCHAR CHARACTER
    TIMESTAMP DATETIME
    VARBINARY RAW

    If the ResultSet contains any other type, an exception is thrown.

  • Extend the OpenEdge InputResultSet if:
    • The ResultSet contains a column type other than the types shown in the previous table and the column can be converted to a compliant type, implement your own ResultSet class instead of passing the java.sql.ResultSet directly as the parameter. For example, you can extend com.progress.open4gl.InputResultSet with your own class.

    • When getObject() is called on your class, it retrieves data from the corresponding standard object and converts the data before returning it to the proxy. When the getMetaData() method is called, the implementation of your extended class must supply the appropriate meta data. To do this, the application must create and populate a ProResultSetMetaDataImpl object, as described in ProResultSetMetaDataImpl class.

    • The application requires the resulting server-side temp-table to have an array field, this is another reason for you to extend the InputResultSet class. This time, the implementation of both next() and getObject() call the standard instance's corresponding methods to do the work. When the getMetaData() method is called, however, the extending class must supply the required meta data, with the flattened schema view converted to the corresponding array field view. Again, to do this, the application must create and populate a ProResultSetMetaDataImpl object, as described in ProResultSetMetaDataImpl class.
  • Use the ResultSetMetaData from a previously obtained output ResultSet under the following condition:
    • If the input ResultSet is a ResultSet that was first obtained from the application server through an OUTPUT parameter, meta data can be obtained from that output set by calling getMetaData() on it. You can think of this as an OUTPUT-INPUT TABLE-HANDLE, parameter even though it is output from one method call and input through another. The ResultSetMetaData object obtained from the output ResultSet can then be provided when getMetaData() is called for the input ResultSet.