Removes the semicolon at end of oracle CREATE TABLE queries and adds a
semicolon to the end of a SELECT query inside of the trigger for a new
table's auto increment column before the end keyword
PHPBB3-10214
* develop-olympus:
[ticket/9892] Correct copyright year
[ticket/9892] Remove incorrect use of camel case
[ticket/9892] Removing closing php tag from create_schema_files
[ticket/9892] Transaction support for database update sql execution function
[ticket/9892] count is a keyword in firebird, so renaming this alias
[ticket/9892] Q&A CAPTCHA did not work on firebird, so no need to change config
[ticket/9892] Shorten login_attempt key names to avoid firebird length problems
[ticket/9892] Drop Q&A CAPTCHA tables if left in inconsistent state
[ticket/9892] Adding a number of tests for db_tools
[ticket/9892] Table prefix lengths influence index lengths in db_tools
[ticket/9892] Shorten the index names on the q&a captcha
[ticket/9892] column & index name limits, firebird auto increment in db_tools
Conflicts:
phpBB/develop/create_schema_files.php
- Column names are limited to 30 characters
- Index names are limited to 31 characters.
On some dbms the index name contains both table name and actual index name
so the limit applies to the sum of the lenghts of table name and index name.
- Auto incremented column names are limited to 26 characters to provide an
additional 4 characters for sequence names
The code for firebird auto increment support using generators/sequences with
triggers was copied from create_schema_files.php
PHPBB3-9892
* develop-olympus:
[ticket/9992] Clarify explanations of ip and account limits on login
[ticket/9992] Add a comma to language for IP_LOGIN_LIMIT_MAX_EXPLAIN
[ticket/9992] Use sql_fetchfield for single row and single column result
[ticket/9992] Adding a limit on login attempts per IP.
[ticket/9992] Make sql_create_table and sql_table_exists available in updater
A new table was created to save all failed login attempts with
corresponding information on username, ip and useragent. By default
the limit is 50 login attempts within 6 hours per IP. The limit is
relatively high to avoid big problems on sites behind a reverse
proxy that don't receive the forwarded-for value as REMOTE_ADDR but
see all users as coming from the same IP address. But if these
users run into problems a special forwarded-for option is available
to limit logins by forwarded-for value instead of ip.
PHPBB3-9992
* develop-olympus:
[ticket/9685] Test for databases that are able to nest transactions
[ticket/9685] Consistently name the new sql_buffer_nested_transactions function
* develop-olympus:
[ticket/10003] Delete EOL at EOF for the benefit of 3.0 modifications.
[ticket/10003] Ported 1802b9ff9286a7fc24493e71b3432816cbdbfcd8 to db_tools.
[ticket/10003] Ported 5553cfc2ed81ba9eb571804c431def962720b39e to db_tools.
[ticket/10003] Ported 023760c8b2402418310a3717db8349cac0342e42 to db_tools.
[ticket/10003] Ported 54c22ae52a0e18232cac8fed342ea52f2e2a793d to db_tools.
[ticket/10003] Ported 96a30afcca3ebd832c9b3083bb5c9a9f2a2dc54b to db_tools.
[ticket/10003] Ported d7d96223e7bae7cd60b13c6e7896d95838c3633c to db_tools.
To have a generic solution there is now a sql_buffer_nested_transaction()
which indicates that the given SQL driver requires buffering to run a
transaction while iterating over another result set.
PHPBB3-9685
pg_last_error does not work if no connection was ever established.
Therefore we must keep track of connection errors in postgres
dbal ourselves.
PHPBB3-10057
Calling nonexistent functions with @ destroys the script with
no feedback as to the cause of the error. Check whether
interbase functions exist before calling them.
PHPBB3-10057
Addresses two issues:
1. When pgsql extension is missing, @pg_connect would silently
abort execution. Check for pg_connect existence before calling it,
same with pg_pconnect.
2. When connection fails, the error reported by php is discarded.
User is shown the failure message without the reason for failure,
making debugging difficult. Collect the error (if any) via a
temporarily installed error handler, and display it if connection
failed.
PHPBB3-10057
* task/naderman/mssql-db-tests:
[task/mssql-db-tests] Remove MS SQL helper values from SELECT LIMIT results.
[task/mssql-db-tests] Split up database tests into SELECT and write operations
[task/mssql-db-tests] PHPUnit output got stuck after unterminated ob_start.
[task/mssql-db-tests] sql_query_limit must return all results when total = 0
[task/mssql-db-tests] Add support for odbc & sqlsrv PDO test connections
[task/mssql-db-tests] Refactored getConnection into multiple smaller parts.
[task/mssql-db-tests] Allow test configuration with environment variables.
[task/mssql-db-tests] No longer display an error when skipping db tests.
[task/mssql-db-tests] Use a simple getter for test case helpers.
We require version 1.1 of the sqlsrv extension anyway so the regular
sqlsrv_num_rows can be used instead of buffering the result. The result
buffer (class result_mssqlnative) should never automatically free the
resource it receives - we consistently close resources using sql_freeresult().
PHPBB3-9686
* ticket/evil3/8944:
[ticket/8944] Patch db_tools to support index length for MySQL4
[ticket/8944] Add index length to CREATE INDEX for MySQL4 in database_update
The native SQL Server plugin used to return an error string when calling
sql_error. However, some error condition checks are done using is_array.
This patch wraps the error into an array to follow the error logic used
elsewhere.
PHPBB3-9521
Because the existing cache is global, there is no way to differentiate between
each of two databases which may be two different DBAL objects pointing to
servers with wildly different versions of an RDBMS. phpBB only has this
situation in the UCF, thus only one file changed outside the DBAL. I have
added a second optional parameter, $use_cache to each of the implementations
of dbal::sql_server_info()
PHPBB3-9637
This reverts Oracle support to the state it was in prior to phpBB 3.0.6. That is, storage of long strings works again (e.g. posts > 4 KB), but the database backup/restore functionality is broken. We feel that the ability to store long strings is more important than the DB restore, since Oracle 10g itself provides tools for backing up databases.
PHPBB3-9132
pg_connect() takes an integer as the second parameter, but we were passing a boolean parameter. The function especially requires passing the PGSQL_CONNECT_FORCE_NEW constant if a new connection is to be forced. Passing 0 as the second parameter for 'do not force a new connection' doesn't work as expected, hence we're calling the function without a second parameter in this case.
PHPBB3-9518
