Executing prepared statements is succesfull only for the first two statements
The reworked patch descends to the bug #69526 which is fixed by
this as well. The broken logic in the current code was, that
SQLDescribeParam was executed in odbc_execute every time. This piece
is now moved into odbc_prepare and the results are carried on in an
additional structure.
Since the ext/odbc headers are not being currently installed and the
corresponding structs like odbc_result are not used outside ext/odbc,
the binary compatibility persists. Executing SQLDescribeParam only once
in odbc_prepare is also an optimization as the filds usually won't
change that fast and thus requestind the descriptions on every
execution is not required.
This is done in two steps:
- the ODBCVER has to be rased to 0x0300 which corresponds to Sql
Server 9, otherwise the client will not recognize several SQL
datatypes
- additionally the config scripts was tweaked so then ODBCVER
can be overridden, that still allows enabling compatibility
with lower versions
Bug #67437 might be fixed by this as well.
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.
The ODBC extension did not support WVARCHAR. WVARCHAR ends up being handled by
the default handler where vallen is set by the driver to the actual bytes
needed for the field. If it is larger than default-lrl then the output is
corrupted (reading past the buffer) because the return functions don't expect
that to happen. The patch add support to handle WVARCHAR just like a regular
VARCHAR.
(clara@zealworks.com).
# I haven't had time to completely test this patch, a few users have stated
# that it works well for them and a few others want to test with windows
# builds, hence the submission.
. Changed the configure/compile so that it doesn't "pollute" the INCLUDES
anymore and thus cause trouble with other extensions which
might use the same header files. (e.g. Informix)
. Separated the #include statements to own file so we don't get any
errors when compiling main/internal_functions.c
