| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
# Conflicts:
# adodb-time.inc.php
# docs/changelog.md
# drivers/adodb-mssql.inc.php
# drivers/adodb-mssqlnative.inc.php
# drivers/adodb-oci8po.inc.php
|
|
|
|
|
|
|
|
|
|
|
|
Commit 53d13c0f64ad97ff87fa3b74fa4a4e896e691c9b (fixing #58 and #63)
introduced a regression in 5.20.0 that broke connections LDAP when using
URIs like ldap:// or ldaps://.
Create a new protected method ADOConnection::parseHostNameAndPort() to
help parse off the port from a hostname while retaining the ldap:// or
ldaps:// scheme, and use it to refactor Connect() and PConnect().
Fixes #340
Signed-off-by: Damien Regad <dregad@mantisbt.org>
The PR's original commits were squashed and the message reworded. The
fix (initially targeted at master) was applied to hotfix/5.20 branch.
|
|
|
|
Conflicts:
adodb.inc.php
docs/changelog.md
|
|
The PHP native `$php_errormsg` variable has been deprecated as of PHP
7.2. The recommended replacement is `error_get_last()`.
A number of the driver classes used `$php_errormsg` to track if a DB
action caused an error.
As the `error_get_last()` function returns an array and comparing the
message therefore is slightly more involved, two new methods have been
introduced into the abstract parent class `ADOConnection` to handle the
message comparison.
The `resetLastError()` method retrieves the initial (old) error message
and resets it to enable checking whether a new error has occurred, even
when the new error is the same as the previous one.
The new `getChangedErrorMsg()` method compares the old error message
with the current one to determine whether a new message has occurred,
and if so, returns the message.
Refs:
* http://php.net/manual/en/migration72.deprecated.php#migration72.deprecated.track_errors-and-php_errormsg
* http://php.net/manual/en/reserved.variables.phperrormsg.php
* http://php.net/manual/en/function.error-get-last.php
Additional notes:
* In the `ADODB_ads::UpdateBlob()` method, the original (old) message
was not being retrieved which could result in an unrelated error being
recorded. This has been fixed.
* In the `ADODB_db2::_connect()` and `ADODB_db2::_pconnect()` methods,
the `$php_errormsg` was being reset, but subsequently not checked for
changes, so as the variable in effect was not being used, I've removed
the related code.
* In the `ADODB_sybase::ErrorMsg()` method, the `$php_errormsg` was
being checked, but no functions which could potential cause errors are
being called. As `$php_errormsg` is only available in the scope an
error occurred in, this meant that `$php_errormsg` would always be
empty, so I've removed the related code.
Fixes #409
|
|
|
|
Cherry-pick + squash of commits
- 5c5ee9e953dd0caf978630b1c3147447d6cb58a7
- c8524bb3fcd291fe6233643fb43e9ceeb8aef925
|
|
Backported from d9cc6c66ec08e5a517f8fa4503345ead992e2a62. I meant to do
this in 5.20.10 but I forgot...
Fixes #373
|
|
|
|
|
|
|
|
To avoid unwanted information disclosure if an error occurs when
loading a database driver, we should not output the full path in the
error message.
Fixes #389
|
|
https://pecl.php.net/package/memcached
Fixes #322
|
|
|
|
We had a problem in our app using the pdo_sqlsrv driver with PHP 7 that
manifested itself by a ODBC32.dll crash at the end of a PHP request
(see issue: https://github.com/Microsoft/msphpsql/issues/434).
It seems the dll tried to free a statement after the connection had been
disconnected.
We looked at our code and the ADOdb code to see if a reference to a
statement could imply that it would be garbage-collected after the PDO
disconnection.
We found that `ADODB_pdo#_query` returns a statement to
`ADOConnection#_Execute` which stores it in its `_queryID` property and
never empties it explicitly.
Setting it to `false` in `ADOConnection#Close` seems to fix the problem
in our app.
Fixes #379
|
|
Currently when defining $ADODB_OUTP you can set a custom output
function. However i want to use an object method as an output handler.
So now $ADODB_OUTP is fed to call_user_func so we can set:
$ADODB_OUTP=array($object,'output_method');
Fixes #312
|
|
|
|
|
|
|
|
Most of the includes in adodb.inc.php are done with include_once but
in a couple locations its still done with include.
This is the case for adodb-lib.inc.php which is conditionally included
based on a global var. I ran into problems with running adodb in debug
mode while running phpunit tests. Phpunit will reset the global vars
and thus break the include mechanism. This is a problem of phpunit
and can be worked around. However it would make adodb more robust
to just use include_once everywhere. It will remove the dependency on
the $ADODB_INCLUDED_LIB global var.
I also replaced one include statement in adodb-time.inc.php, in various
drivers and other files too, so include_once is used everywhere.
Signed-off-by: Damien Regad <dregad@mantisbt.org>
|
|
|
|
see #350
|
|
Changed tabs in annotations to spaces
Fixes #345
|
|
Fixes #344
|
|
|
|
ADODB_ASSOC_CASE constant, but should be used as presented
by the database. see #335
|
|
|
|
|
|
The ADOdb Extension's development stopped at version 5.04. It is no
longer maintained or supported, yet the library still contains code
referencing it. If those code branches are executed, ADOdb will not
perform properly, due to missing constant declarations (among other
things).
This commit removes all references to the Extension.
Fixes #270, #269
|
|
|
|
|
|
|
|
PDO uses a slightly different naming convention for the recordset class
if the database type is changed. This meant that the _execute() function
could not locate the recordset class.
The code now includes a specific test for PDO drivers to allow the class
to be located.
Fixes #245
|
|
|
|
|
|
|
|
When the old ADOdb extension is installed and a more recent version of
ADOdb is running, a PHP warning 'undefined constant
ADODB_ASSOC_CASE_NATIVE' is thrown.
The PHP Extension is obsolete and unsupported, so we shouldn't even try
to run when it is loaded.
This commit will cause ADOdb to exit with an error (or throw an
exception if adodb-exceptions.inc.php has been included) if the
Extension is detected.
Fixes #269
|
|
Conflicts:
docs/changelog.md
|
|
|
|
|
|
When connecting to a database using mysqli driver and the corresponding
PHP extension is extension is not loaded, ADOdb dies with exit code 255
signaling a fatal error. This is due to ADODB_mysqli::ErrorNo() calling
mysqli_connect_errno() with the '@' operator, suppressing the 'Call to
undefined function' fatal error.
When not using adodb-exceptions, setting `$db->debug=true;` causes ADOdb
to print message 'Missing extension for mysql', but this is not the case
when exceptions are used.
To fix the problem, we only call the ErrorNo() method when the result of
_connect() is set, and otherwise pass arbitrary error number 0 with the
missing extension message to the exception handler.
Fixes #254
|
|
If you pass pdo_mssql, pdo_mysql, etc to ADONewConnection() there's a
fatal error that occurs when ADOLoadCode() includes the subclass file,
because ADODB_pdo is undefined.
'pdo_*' arguments are now rejected with an error message instead of
failing silently.
Fix #241
Signed-off-by: Damien Regad <dregad@mantisbt.org>
Changes to original commit
- code block moved within switch statement's default block to avoid
unnecessary overhead when we already know the the db type will not
match.
- message reworded, added PR reference
|
|
|
|
These new methods provide a simple shortcut to a timestamp field
formatted with the following values:
- Day as zero padded 2 digit number
- Month as zero padded 2 digit number
- Year as 4 digit number
The methods are documented in the ADOdb reference manual.
The sqlite version of these methods avoids the DST issue with sqlDate() by
directly calling the native date functions instead of adodb_date().
Fixes #225
|
|
ADOdb contains a portable connection::substring connection identifier, but
it could not be successfully used to create portable substring SQL code when
used with SQL Server, because that driver requires a mandatory 3rd length parameter
which differs from most other databases.
|
