Scalar Type Mappings

A limited number of scalar VARIANT data types are supported. The types of the values supplied as input must be compatible with the OpenROAD data type of the corresponding parameter (or user class attribute) in the 4GL procedure. The following table describes these compatible mappings:

Input VARIANT Type	Compatible OpenROAD Types
VT_I2	INTEGER, SMALLINT
VT_I4	INTEGER, SMALLINT
VT_R4	FLOAT, DECIMAL
VT_R8	FLOAT, DECIMAL
VT_DECIMAL	DECIMAL
VT_CY	MONEY
VT_DATE	DATE
VT_BSTR	VARCHAR, STRINGOBJECT
Array of VT_UI1	LONGBYTEOBJECT, BITMAPOBJECT

For the purposes of data mapping, the OpenROAD StringObject, LongByteObject, and BitmapObject types are considered to be scalar types, as is the VARIANT “one-dimensional array of VT_UI1.”

On output, the OpenROAD types are mapped back into VARIANT data types, as described in the following table:

OpenROAD Type	Resulting Output VARIANT Type
DATE	VT_DATE
DECIMAL	VT_DECIMAL
FLOAT	VT_R8
INTEGER	VT_I4
MONEY	VT_CY
SMALLINT	VT_I2
VARCHAR	VT_BSTR
STRINGOBJECT	VT_BSTR
LONGBYTEOBJECT	Array of VT_UI1
BITMAPOBJECT	Array of VT_UI1

Note: VARCHAR data is character data, not binary, and is converted to UNICODE for the VT_BSTR. LongByteObject data is binary data, and treated as an uninterpreted stream of bytes.

With ByRef parameters, it is possible that some VARIANT values may go in as one data type and come back as a slightly different (compatible) data type. This is not an issue for programmers using the OpenROAD 4GL RemoteServer system class interface, but programmers using other languages should be aware of the possibility. For example, a VT_R8 could be mapped to a 4GL DECIMAL on input, but when it is output, the 4GL DECIMAL is converted to a VT_DECIMAL. The Parameter Data Object hides this detail because the PDO automatically coerces all returned data back to the type with which it was declared in the PDO.