Try OpenEdge Now
skip to main content
Java Open Clients
Passing Temp-tables as SQL ResultSet Parameters : Passing a TABLE or TABLE-HANDLE as an INPUT parameter : Providing metadata for INPUT TABLE-HANDLE parameters
 

Providing metadata for INPUT TABLE-HANDLE parameters

For TABLE parameters, the proxy calls the next() and getObject() methods to get the data that needs to be passed to the AppServer 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 40. 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 AppServer 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.
* ProResultSetMetaDataImpl class