As of PHP 8.1.0, passing `null` to an `int` parameter is deprecated,
and as such the deprecation notice breaks the test. So we instead pass
an integer, and to avoid hard-coding a value we just add the two
supported constants (which are supposed to have the values `1` and `2`,
respectively).
Closes GH-15254.
These changes are carved off from https://github.com/php/php-src/pull/12040/files. I noticed that there are some inconsistencies between odbc_fetch_object()/odbc_fetch_array(), odbc_fetch_into(), as well as odbc_fetch_row(), specifically in how they handle the $row parameter. Now, I tried to align their behaviour the following way:
- I made null the default value. Previously, the default values were one of the following: -1, -1, 0, and null, respectively.
- odbc_fetch_row() has been returning false indicating there is no more rows when 0 is passed as $row. Now, a warning is also emitted in this case, because the null default value is not new, because it's available since PHP 8.0.
- When HAVE_SQL_EXTENDED_FETCH is not defined, the $row parameter is always ignored. Previously, some of the functions didn't accept it at all. Now a warning is emitted if the feature is not supported, but the parameter has any meaningful value (is greater than or equal to 1).
SQL Server frequently deadlocks. Parallelization of these jobs, at least in CI,
is not worthwhile because there are enough tests to run in parallel for the few
workers available.
Declare and initialize on one line
changed to use php_memnistr
store strlen(db) in a variable
Added a semicolon to the end of dsn.
If there is a semicolon at the end of the original dsn, it will be duplicated, so it will be removed.
Add condition when authentication information is null
`ext/odbc/tests/config.inc` overrides the INIs used for the ODBC driver
manager pointlessly. It's not pointing to some custom PHP test suite
specific one, but the system one in `/etc/odbc(inst).ini`. Which
doesn't necessarily exist, on i.e. NixOS, MacPorts, etc.
Closes GH-12133
Signed-off-by: George Peter Banyard <girgias@php.net>
Like oci8, procedural ODBC uses an apply function on the hash list to
enumerate persistent connections and close the specific one. However,
this function take zvals, not resources. However, it was getting casted
as such, causing it to interpret the pointer incorrectly. This could
have caused other issues, but mostly manifested as failing to close the
connection even fi it matched.
The function now takes a zval and gets the resource from that. In
addition, it also removes the cast of the function pointer and moves
casting to the function body, to avoid possible confusion like this in
refactors again. It also cleans up style and uses constants in the
function body.
Closes GH-12132
Signed-off-by: George Peter Banyard <girgias@php.net>
Hopefully, intermittent test failures will be fixed by creating and using a separate database.
Furthermore, more meaningful test cases are added which also assert the output, as well as wildcard character based searching.
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.
If these tests fail with a fatal error, they won't properly clean up,
which likely causes other tests to fail as (several ODBC tests use the
`odbcTEST` database and tables or stored procedures named `FOO`). This
is particularly annoying during development, where you would need to
clean up manually.
We fix this by moving the cleanup code to the --CLEAN-- section, so
that this code is executed no matter what.
Closes GH-7886.
This deprecates passing null to non-nullable scale arguments of
internal functions, with the eventual goal of making the behavior
consistent with userland functions, where null is never accepted
for non-nullable arguments.
This change is expected to cause quite a lot of fallout. In most
cases, calling code should be adjusted to avoid passing null. In
some cases, PHP should be adjusted to make some function arguments
nullable. I have already fixed a number of functions before landing
this, but feel free to file a bug if you encounter a function that
doesn't accept null, but probably should. (The rule of thumb for
this to be applicable is that the function must have special behavior
for 0 or "", which is distinct from the natural behavior of the
parameter.)
RFC: https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
Closes GH-6475.
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.
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.
