Fix handling of single-key connection strings

A connection string may contain just a single key, but
PHP used ";" as the heuristic to detect if a string was a connection
string versu

Fix handling of single-key connection strings

A connection string may contain just a single key, but
PHP used ";" as the heuristic to detect if a string was a connection
string versus plain DSN. However, a single-key connection string
would get treated like a DSN name, i.e. "DSN=*LOCAL". This makes it
so that "=" is used, as a connection string must contain a key.

Closes GH-8748.

show more ...

Remove incorrect format argument

rc is not used by the printf format.

Fix #80460: ODBC doesn't account for SQL_NO_TOTAL indicator

The `StrLen_or_IndPtr` parameter usually may be `SQL_NO_TOTAL`; we need
to cater to that possibility to avoid working with neg

Fix #80460: ODBC doesn't account for SQL_NO_TOTAL indicator

The `StrLen_or_IndPtr` parameter usually may be `SQL_NO_TOTAL`; we need
to cater to that possibility to avoid working with negative string
lengths and other issues. A noteable exemption are calls to
`SQLGetData()` which return `SQL_SUCCESS`; in that case `SQL_NO_TOTAL`
can not occur.

Closes GH-6809.

show more ...

Fix #80592: all floats are the same in ODBC parameters

We must not release the strings until we are done with them.

Closes GH-6579.

Fix format specifier

In this function, `i` is of type `size_t`.

Fix #44618: Fetching may rely on uninitialized data

Unless `SQLGetData()` returns `SQL_SUCCESS` or `SQL_SUCCESS_WITH_INFO`,
the `StrLen_or_IndPtr` output argument is not guaranteed to be

Fix #44618: Fetching may rely on uninitialized data

Unless `SQLGetData()` returns `SQL_SUCCESS` or `SQL_SUCCESS_WITH_INFO`,
the `StrLen_or_IndPtr` output argument is not guaranteed to be properly
set. Thus we handle retrieval failure other than `SQL_ERROR` by
yielding `false` for those column values and raising a warning.

Closes GH-6281.

show more ...

Change parameters types from int to bool

These are typical boolean parameters, so we shouldn't advertize them as
integers. For the `$reverse` parameter that even fixes expectations,

Change parameters types from int to bool

These are typical boolean parameters, so we shouldn't advertize them as
integers. For the `$reverse` parameter that even fixes expectations,
because the `reverse` member is a bitfield of 1 bit, so assigning any
even integer would not set it.

Closes GH-6328.

show more ...

Don't separate array parameter

Closes GH-6243.

Fix #46050: odbc_next_result corrupts prepared resource

When resetting the result's values, we also have to reset its numcols.

Revert "Use external iterator instead of via the internal pointer"

This reverts commit a6ecafece90909d74a578e09f626e875d3035eab.

Closes GH-6242.

Fix recently introduced off-by-one error

Remove unused variable

Use external iterator instead of via the internal pointer

Fix #80152: odbc_execute() moves internal pointer of $params

As least intrusive fix, we separate the passed array argument.

Closes GH-6219.

Fix #22986: odbc_connect() may reuse persistent connection

`odbc_connect()` should not reuse persistent connections, since that
prohibits multiple concurrent connections, which are occas

Fix #22986: odbc_connect() may reuse persistent connection

`odbc_connect()` should not reuse persistent connections, since that
prohibits multiple concurrent connections, which are occasionally
desireable. We fix that by no longer looking for already cached
connections when `odbc_connect()` is called, and instead creating a new
connection instead.

Closes GH-6223.

show more ...

Fix #80150: Failure to fetch error message

In case of statement related errors, we need to pass the respective
statement handle to `SQLError()`.

Closes GH-6217.

Fix #80147: BINARY strings may not be properly zero-terminated

We have to manually ensure that all strings fetched from a data source
are zero-terminated.

Closes GH-6213.

Fix UNKNOWN default values in ext/odbc

Closes GH-6154

Fix #78470: odbc_specialcolumns() no longer accepts $nullable

It is mandatory to pass either `SQL_NO_NULLS` or `SQL_NULLABLE` as
tenth parameter to `SQLSpecialColumns()`; otherwise the f

Fix #78470: odbc_specialcolumns() no longer accepts $nullable

It is mandatory to pass either `SQL_NO_NULLS` or `SQL_NULLABLE` as
tenth parameter to `SQLSpecialColumns()`; otherwise the function call
fails. Therefore the user must be allowed to pass the desired value
as parameter to `odbc_specialcolumns()` again.

Closes GH-6200.

show more ...

Fix compilation warnings in odbc

SQLCHAR* cast all the things.

Promote warning to Error in ODBC extension

Closes GH-6123

Move custom type checks to ZPP

Closes GH-6034

Remove proto comments from C files

Closes GH-5758

Fixed possible usage of uninitialized value

Fix [-Wundef] warning in ODBC extension