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.
Because the UID= and PWD= values are appended to the SQLDriverConnect
case when credentials are passed, we have to append them to the string
in case users are relying on this behaviour. However, they must be
quoted, or the arguments will be invalid (or possibly more injected).
This means users had to quote arguments or append credentials to the raw
connection string themselves.
It seems that ODBC quoting rules are consistent enough (and that
Microsoft trusts them enough to encode into the .NET BCL) that we can
actually check if the string is already quoted (in case a user is
already quoting because of this not being fixed), and if not, apply the
appropriate ODBC quoting rules.
This is because the code exists in main/, and are shared between
both ODBC extensions, so it doesn't make sense for it to only exist
in one or the other. There may be a better spot for it.
Closes GH-8307.
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
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.
We're starting to see a mix between uses of zend_bool and bool.
Replace all usages with the standard bool type everywhere.
Of course, zend_bool is retained as an alias.
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.
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.
`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.
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.
Christoph M. Becker