The SQL Server Native Client 11.0 and maybe other ODBC drivers report
NVARCHAR(MAX) columns as SQL_WVARCHAR with size 0. This causes too small a
buffer to be emalloc'd, likely causing a segfault in the following. As we don't
know the real size of the column data, we treat such colums as
SQL_WLONGVARCHAR.
The related bug #67437 suggests that some drivers report a size of ~4GB. It is
not certain that this is really the case (there might be some integer overflow
involved, and anyway, there has been no feedback), so we do not cater for this
now. However, it would not be hard to treat all sizes above a certain threshold
in a similar way, i.e. as SQL_WLONGVARCHAR.
Temporary variable indicating column field type ID should be
reset to default for loop iteration (i.e. every column in the
record set. The old buggy code made it persist across all columns
leading to invalid reads from the buffer, if for example a DATE
column was preceded by a VARCHAR column.
For unixODBC, use ODBC version as defined by it (as of v2.2.14 it is 3.5).
This allows us to use newer features like SQL_DESC_OCTET_LENGTH (which
returns the number of bytes required to store the data). This fixes the issue
in #60616. If the newer version is not available, over-allocate to accomodate
4-byte Unicode characters for CHAR and VARCHAR datatypes (and their Wide
counterparts).
version.
Fixed a couple of failing tests.
