mirror of
https://github.com/FirebirdSQL/firebird.git
synced 2025-01-23 00:43:02 +01:00
140 lines
6.8 KiB
Plaintext
140 lines
6.8 KiB
Plaintext
********************************************************************************
|
|
LIST OF KNOWN INCOMPATIBILITIES
|
|
between versions 1.5.x and 2.x
|
|
********************************************************************************
|
|
|
|
This document describes all the changes that make v2.0 incompatible in any way
|
|
as compared with the previous release and hence could affect your databases and
|
|
applications.
|
|
|
|
Please read the below descriptions carefully before upgrading your software to
|
|
the new Firebird version.
|
|
|
|
INSTALLATION/CONFIGURATION
|
|
--------------------------
|
|
|
|
* Security database is renamed to security2.fdb. If you upgrade the existing
|
|
installation, please be sure to upgrade the security database using the
|
|
provided script in order to keep your users' logins. For more details see
|
|
$FBROOT/upgrade/security_database.txt.
|
|
Simple 'cp security.fdb security2.fdb' makes is impossible to attach
|
|
to the firebird server !
|
|
|
|
* Password hashes are now generated using the SHA-1 algorithm instead of the
|
|
old DES one. If you want to preserve the already existing security database
|
|
(i.e. upgrade it using security_database.sql script), you'll need to set the
|
|
LegacyHash config option to 1 (TRUE). However, it's recommended to return
|
|
it's value back to default (after changing user's passwords) in order
|
|
to keep your installation safe.
|
|
|
|
* The new client library is not compatible with the older server (and vice
|
|
versa) in regard to the local protocol, as the transport internals has been
|
|
reimplemented (XNET instead of IPServer). If you need to use the local
|
|
protocol, please ensure your server and client binaries are of the same
|
|
version.
|
|
|
|
SECURITY
|
|
--------------------------
|
|
|
|
* Direct connections to the security database are not allowed anymore. This is
|
|
done for security reasons and also in order to isolate authentication
|
|
mechanisms from the implementation. You should use Services API or GSEC
|
|
to configurate user accounts instead. To backup the security database always
|
|
use Services API. Switch -SE of gbak utility may be used for this purpose.
|
|
|
|
* Non-SYSDBA users no longer can see accounts of other users in the security
|
|
database. A non-privileged user can only retrieve/modify its own account,
|
|
including a password change.
|
|
|
|
* Remote attachments to the server without login/password are prohibited.
|
|
It means, particularly, that all attachments to SuperServer (even by root
|
|
without explicit localhost: in database name) without correct login will
|
|
be rejected by remote interface. Embedded access without login/password
|
|
works fine (unix user name is used to validate access to database's
|
|
objects).
|
|
|
|
UTILITIES
|
|
--------------------------
|
|
|
|
* GBAK -R (former shortcut for "-REPLACE_DATABASE") no longer overwrites an
|
|
existing database during restore, it reports an error instead. In order to
|
|
use the previous behaviour, you may specify either the full syntax
|
|
"GBAK -REPLACE_DATABASE" or use the new command
|
|
"-R[ECREATE_DATABASE] OVERWRITE". The "-R" shortcut is now considered to
|
|
represent the "-R[ECREATE_DATABASE]" command, while "-REP" is offered as a
|
|
new shortcut for "-REP[LACE_DATABASE]". This change is targeted to prevent
|
|
accidental database overwrites by the users treating "-R" as "restore".
|
|
Those using the full syntax are expected to know what this restore mode
|
|
actually means.
|
|
|
|
SQL CHECKING
|
|
--------------------------
|
|
|
|
* It's now prohibited to reference columns of an aliased table using the table
|
|
name, e.g. "SELECT TAB.A FROM TAB T". You should use the table alias
|
|
instead: "SELECT T.A FROM TAB T". Such behaviour is declared by the SQL
|
|
specification.
|
|
|
|
SQL SYNTAX
|
|
--------------------------
|
|
|
|
* CLOSE became reserved keyword according to SQL standard (CLOSE CURSOR).
|
|
It's now prohibited to use it as general purpose identifier without quotes.
|
|
For example, 'declare variable close smallint;' results in error.
|
|
|
|
SQL EXECUTION RESULTS
|
|
--------------------------
|
|
|
|
* NULLs are now considered the least possible values in terms of the ordering
|
|
and they are sorted accordingly. This means that NULLs are placed in the
|
|
beginning of the result set for ascending sorts and in the end for
|
|
descending sorts. In the previous versions, NULLs were always on top. If
|
|
you rely on the legacy NULLs placement, please use the NULLS FIRST option
|
|
in your ORDER BY clauses.
|
|
|
|
* Views updatable via triggers no longer perform direct table operations. In
|
|
previous versions, a naturally updatable view with triggers passed the DML
|
|
operation to the underlying table as well as executed the triggers. So if
|
|
you followed the official documentation and used triggers to perform a table
|
|
update, this update was actually done twice, causing either performance
|
|
issues or errors (if blobs were affected). Now availability of triggers turn
|
|
direct table updates off and everything depends on your triggers. If you
|
|
rely on the legacy undocumented behaviour (e.g. use triggers for logging
|
|
purposes only), you'll need to adjust your triggers to perform actual
|
|
updates as well.
|
|
|
|
* CURRENT_TIMESTAMP now returns milliseconds by default, while it returned
|
|
truncated seconds value in the previous versions. If you don't need second
|
|
fractions here, please specify the required accuracy explicitly, e.g. use
|
|
CURRENT_TIMESTAMP(0).
|
|
|
|
* ORDER BY now expands asterisks in the select list when referencing columns
|
|
by ordinal. So now "SELECT T1.*, T2.COL FROM T1, T2 ORDER BY 2" sorts on the
|
|
second column of table T1, while the previous versions sorted on T2.COL.
|
|
However, this change makes queries like "SELECT * FROM TAB ORDER BY 5"
|
|
possible.
|
|
|
|
PERFORMANCE
|
|
--------------------------
|
|
|
|
* In SuperServer, garbage collection is now performed in the combined mode
|
|
(cooperative + background) by default, whilst previous versions used only
|
|
background garbage collection. It means that some queries may return data
|
|
slower when there are enough old record versions in the affected tables
|
|
(this is especially true for ODS10 and below databases which has ineffective
|
|
garbage collection in indices). Please note the new behaviour generally
|
|
guarantees better overall performance as the garbage collection is performed
|
|
online and it prevents version chains from growing under high load. But you
|
|
can rollback to the older behaviour using the GCPolicy config option.
|
|
|
|
* This version never uses indices for the ALL predicate and it can cause a
|
|
performance degradation for some your queries. This is done to fix known
|
|
bugs causing wrong results returned by this predicate in cases when index
|
|
was involved.
|
|
|
|
FIREBIRD.CONF
|
|
--------------------------
|
|
|
|
* Parameter DeadThreadsCollection is deprecated and will be ignored if set.
|
|
Current firebird version efficiently performs it without delay.
|