search

microsoft / ODBC-Specification

Microsoft ODBC Specification
Other
121 stars 40 forks source link

SQL_ATTR_LENGTH_EXCEPTION_BEHAVIOR & retrieval of truncated data (What to use for TargetType?) #106

Closed matthew-wozniczka closed 7 years ago

matthew-wozniczka commented 7 years ago

SQL_LE_REPORT allows the application to retrieve data that was truncated while filling a binding.

It's not stated explicitly, but it needs to use the same C-type in SQLGetData as in the binding, correct?

Going farther than that, may I suggest that the application must use SQL_ARD_TYPE (or SQL_APD_TYPE for output parameters) in this scenario?

This would ensure that the target type (+ type parameters like scale, precision, etc) does not change mid-conversion. If the application uses the C type directly, then the current spec says that the defaults for that type should be used, which is incompatible with continuing an already-started conversion.

matthew-wozniczka commented 7 years ago

As an aside, MSDN has this:

If TargetType is SQL_ARD_TYPE, the data type in the SQL_DESC_CONCISE_TYPE field of the ARD is used. If TargetType is either SQL_ARD_TYPE or SQL_C_DEFAULT, the data is given the precision and scale in the SQL_DESC_DATETIME_INTERVAL_PRECISION, SQL_DESC_PRECISION, and SQL_DESC_SCALE fields of the ARD, depending on the data type in the SQL_DESC_CONCISE_TYPE field.

I'm guessing this was written before the advent of custom C types (and retrieving output parameters in parts...)? IMO this should be updated to say that all fields from the ARD will be used.

matthew-wozniczka commented 7 years ago

I think there's a related issue when doing boring old retrieval in parts; there's nothing preventing the application from modifying the ARD in between calls to SQLGetData for a given cell. This means that different 'stages' of the conversion may have different ARDs...

No standard variable-length C types depend on any standard descriptor fields, but relax either of those restrictions and there's an issue (But's not new to ODBC 4).

mikepizzo commented 7 years ago

Agreed. We should clarify that all parts must be retrieved using the same C-type (both in the current SQLGetData scenarios as well as the new SQL_LE_REPORT scenario).

mikepizzo commented 7 years ago

Added to SQL_LE_REPORT that SQLGetData must be called using the SQL_ARD_TYPE or SQL_APD_TYPE, as appropriate.

Clarified that, when retrieving character or binary data in parts, the same C Type must be used for each part.

matthew-wozniczka commented 7 years ago

Section 3.6.1 now says

The application can use SQLGetData to retrieve the remainder of the column/output parameter using the SQL_ARD_TYPE or SQL_APD_TYPE (or the equivalent C type)

Shouldn't the (or the equivalent C type) be removed?