Previous Releases

From InterBase
Jump to: navigation, search

Go Up to What's New in InterBase XE7


Previous Releases

Listed below are the new features from earlier releases: InterBase XE3 Update 4 Hotfix 2: Contains the resolution of known defects. See Resolved Defects for a list of those resolved issues.

InterBase XE3 Update 4: Contains the resolution of known defects. See Resolved Defects for a list of those resolved issues.

InterBase XE3 Update 3: Contains the resolution of known defects. See Resolved Defects for a list of those resolved issues.

InterBase XE3 Update 2: Contains the following new features and enhancements to existing features. See Resolved Defects for a list of resolved issues.

InterBase XE3 Update 1: Contains the following new feature and a significant change to an existing feature. See Resolved Defects for a list of resolved issues.

InterBase XE3: Contains the following new feature and a significant change to an existing feature. Click See Resolved Defects for a list of resolved issues.

Mobile Platforms

The Android platform support is available starting with RAD/Delphi XE6. The iOS platform support was introduced starting with RAD/Delphi XE6.

InterBase XE3 Update 2 introduces InterBase to the Android mobile platform. InterBase ToGo and IBLite editions for Android are available starting with RAD Studio/Delphi XE5. The Trial Edition in RAD Studio XE7 (installable and InstantOn) includes a time-limited license for the IBToGo Test Deployment and IBLite so RAD users can deploy test apps right out of the box.

Developers targeting these mobile platforms can deploy with a ToGo or IBLite license. IBLite is a free deployment with limited capabilities when compared to the InterBase ToGo Edition on the same platform. However, for a fee, you can upgrade IBLite to the InterBase ToGo edition that has additional features. For more information please see: http://www.embarcadero.com/products/interbase/interbase-feature-matrix.pdf.

Requirements and Constraints

  • Requires iOS versions 5.1, 6.0 or above. Devices running earlier versions of the OS are not supported.
  • Requires Android versions 2.3 and above; specifically Android OS versions Gingerbread, ICE, and Jelly Bean. Devices running earlier versions of the OS are not supported.
  • InterBase on Android will NOT support InterBase UDF and Filters to be in line with the feature set on all supported Mobile platforms (both iOS and Android).
  • InterBase applications on Android can work in a pure "Client" mode connecting to remote InterBase servers on the network. For this, InterBase server versions need to be 2009 (9.x) or higher.
  • InterBase applications on Android can only connect with embedded database files with ODS version >= 13. If the database file is copied from a non-Android InterBase platform, this implies that only databases created (or restored) with InterBase 2009 versions or greater are supported.
  • ibconfig limitations: Android devices are equipped with limited RAM as compared to other Desktop/Server machines, so there is a need to keep InterBase footprint smaller with the following parameters:
    • parameter DATABASE_CACHE_PAGES defaults to 75 pages
    • parameter SORTMEM_BUFFER_SIZE defaults to 128KB

Note: Currently ToGo and IBLite are only supported on InterBase XE3, ToGo and IBLite XE3 editions.

  • InterBase with the iOS mobile platform was introduced in InterBase XE3. Both ToGo and IBLite are available for the iOS platform via RAD Studio XE7. The databases deployed on the mobile device can either have centralized user authentication via admin.ib, or use EUA to control user access within the database. VARs and OEMs can now use InterBase on mobile devices by linking their applications with InterBase XE3 ToGo XE3 edition.
  • Applications built for iOS can embed InterBase ToGo with Lite licensing. IBLite is a "free" deployment. This application has limited capabilities when compared to the InterBase ToGo Edition on the same platforms. However, for a fee, you can upgrade IBLite to the InterBase ToGo edition that has additional features.
  • Important: For more information please refer to the ToGoQuickStart.

New Connection Property for InterBase JDBC Apps

InterBase XE3 Update 3 introduced a new connection property in the JDBC driver, returnColumnLabelAsColumnName. Pentaho requires ResultSetMetaData.getColumnName() to actually return the alias/label name (if provided by the application). In order to comply with JDBC specs, and to keep backward compatibility for existing InterBase JDBC apps, this new connection property will be FALSE by default.

If you want to use the new property for the Pentaho type behavior, set the following connection property: 

properties.put ("returnColumnLabelAsColumnName", "true")

Important: For more information please refer to the Developer's Guide.

Display Timestamp

With InterBase XE3 Update 3, you can now use the "gbak -v" command to see extended timestamp information. For InterBase Service calls, this information is only printed if the remote server is also InterBase XE3 Update 3 or later.

For IBConsole, if the "Verbose Output" option is enabled, then the same output is returned, just as "gbak verbose" for command line invocations.

GLOBAL TEMPORARY TABLE Support

There is a change in behavior in the GLOBAL TEMPORARY TABLE Support with the InterBase XE3 Update 2 release. When an SQL script is executed ISQL reported a "deadlock" if EXIT is called without COMMIT/ROLLBACK on a global temporary table. To resolve this issue, the GLOBAL TEMPORARY TABLES function has been redesigned which changes the behavior and corrects the deadlock error.

It is no longer possible for transactions emanating from the same connection to see each other's rows in a transaction-specific (ON COMMIT DELETE) temporary table. To do that, you must use a session-specific (ON COMMIT PRESERVE) temporary table that makes all rows visible to transactions starting in the same session. This is still not the same in that the rows will persist until the connection is finished.

Call Home Feature

If you have obtained InterBase from a third party as part of the third party application, it may contain a "call home" feature. This feature makes an automated one-time connection to the Embarcadero Product Registration System to record the following information:

  • The license that is in use
  • The underlying operating system

ODBC Driver Transition

The DataDirect ODBC drivers are no longer shipped with InterBase XE7. InterBase XE7 now includes a new offering of InterBase ODBC driver.

Concurrent Index Creation

When restoring a database, once the data of a table is restored, the indexes for the table can be created all at the same time. This helps the restore response time where there are idle threads/cores that facilitate the engine doing the job that much quicker by benefiting from sharing the cache for table data. Also, re-computing index SELECTIVITY with SET STATISTICS can be concurrent. InterBase XE7 enables one assistant thread for such operations by default; you can adjust the number of concurrent threads available for such operations by modifying the configuration parameter MAX_ASSISTANTS in ibconfig file.

NO RESERVE SPACE for Database and User Tables

This feature is useful if you have very, large databases (VLDB) with tables that are archival in nature. An archival table means that the rows of a table are infrequently or never UPDATED or DELETED; have complex queries, such as aggregates and analytics that process a high percentage of rows; and where indexes are rebuilt and the database is backed and/or restored frequently. These database operations could see a performance improve of 20% or more with a savings in storage space.

By default, InterBase reserves a small amount of space in each data page of a table to optimize UPDATE and DELETE operations on resident rows. This reserve space can amount to 20% or more of the total space occupied by all of the rows of the table. Some tables archive historical data or data that are UPDATED infrequently or not at all and their rows may never be deleted. Database operations that process most or all of the rows, such as backup, restore, index creation, aggregate computation have always suffered performance penalties proportional to this reservation overhead.

For this reason, a CREATE/ALTER TABLE clause is introduced that prevents space reservation and maximizes row packing for the most efficient fill ratio. At the database level, it has been possible to restore a database with the -USE_ALL_SPACE switch so that no space is reserved for any table. To change the storage behavior in a like manner for new or existing databases, the same clause is introduced for CREATE/ALTER DATABASE.

User Interface

To effect the new storage behavior, a non-standard SQL clause is added:

  • CREATE DATABASE <file name> ... [NO] RESERVE SPACE. Clause is presented before the secondary file specification.
  • CREATE TABLE <table name> ... [NO] RESERVE SPACE. Clause is presented after the column list specification and optional ON COMMIT clause for temporary tables.
  • ALTER DATABASE ... SET [NO] RESERVE SPACE. Clause is presented in any order with other SET elements.
  • ALTER TABLE <table name> ... SET [NO] RESERVE SPACE. Clause is presented in any order with other ADD, DROP, ALTER elements

This causes newly INSERTED rows to not reserve space on their data page for a DELETE record version stub, as would normally be the case. Over many row insertions, a decrease in storage size should be observed relative to what the table size would be in the absence of this feature. The optional NO keyword when used with ALTER TABLE toggles the behavior to the alternate state of the current storage behavior for the table.

The NO RESERVE storage modifier is preserved across database backup and restore. This state is stored as flag bit 64 (0x100) of RDB$RELATIONS.RDB$FLAGS for the user's table entry in the system table RDB$RELATIONS.

The clause is displayed by ISQL's SHOW TABLE command following the enumeration of a table's column definitions. It is also visible using ISQL's Extract (-x) command in a syntax-correct manner for the CREATE TABLE output of the respective table listing. The state for database-wide storage behavior is stored in a like manner for the RDB$DATABASE entry in RDB$RELATIONS.

Requirements and Constraints

  • InterBase XE7 can set the NO RESERVE table state against any database ODS it can attach. If the database is copied to an older installed InterBase version, the storage behavior cannot be enforced and subsequent INSERTED rows will reserve space on page for record back versions. This will do no harm other than consume space.
  • ALTERING an existing table to not reserve space has no effect on existing rows. A backup/restore is necessary if this is required, so a user should plan accordingly if it is expected that a table would grow very large. However, newly inserted rows will start to reoccupy that space should the state of a given data page change to indicate that space is available for new rows.
  • When the database-wide state is set to NO RESERVE SPACE, it takes precedence over the setting at the table-level.
  • The Table-level state is "sticky" in that its state is preserved when the database-wide state is toggled back to the default RESERVE SPACE.
  • It is not necessary to detach and re-attach the database for the new settings to take effect.
  • The new keywords RESERVE and SPACE are not "reserved" as SQL keyword tokens.
  • When toggling back to the default behavior there is no output (e.g. RESERVE SPACE) or observable state, except the RDB$RELATIONS.RDB$FLAGS has the RESERVE bit cleared. This is intentional to avoid polluting an otherwise clean ISQL extract with non-standard SQL extensions that might affect portability.
  • You can opt-out from this reservation at restore time by providing the USE_ALL_SPACE option to gbak for the whole database.

Physical Database Portability Between Windows, MacOSX, Linux, iOS, and Android

InterBase makes deployment on Windows, Mac OSX, Linux, iOS, and Android even easier. It allows you to copy database files between Windows 32-bit and 64-bit, MacOSX, Linux, iOS, and Android. You can develop on one platform, create your database on your development platform, and then easily deploy your database to other supported platforms. For example, you can develop with RAD Studio on Windows 32-bit, create your databases, and then just include these databases as is as part of your deployment for Windows 64-bit, Mac OS X, Linux, iOS, and Android.

There are some restrictions and you may not use certain features. If you want to take advantage of these features, they are listed below. This copying feature is certified for a single-file database that does not have the following; UDF or Filters, External Tables, Journaling, Online, and Incremental dumps, and Shadowing.

As in the previous versions of InterBase you can use the GBAK switch -transportable as a "safe" transportable mechanism. This switch permits the database to be restored to another platform supported by InterBase. It is cross- endian compatible, so using gbak -t allows you to move databases between Windows, MacOSX, Linux, iOS, and Android to Solaris.

For more information please refer to the Operations Guide: General Guidelines for Using GBAK.

Note: It is important to note that database files cannot be directly moved from Little Endian to Big Endian platforms and vice-versa.

Features with Restrictions

The features listed below may require additional attention. This usually involves peculiar pathname conventions of platforms, for example, pathname separator, pathname sensitivity, etc.

  • UDF and Filter libraries
  • Multi-file databases
  • External Tables
  • Journaling
  • Online Dump and Incremental Dump
  • Shadow Database files (this feature is not available in ToGo Edition)
  • System Encryption Password (External SEP storage functionality has NodeID dependency)
  • Database file names on disk are case-sensitive on some platforms (UNIX) and case-insensitive on others.
  • Be aware of this when you are directly mentioning a database filesname in your connection URL, or, using features that use the database file name (like Database Aliasing)

It is not possible to certify all the different ways of copying an InterBase multifile DB configuration. So you have to be aware of issues for your particular environment. An option is to simplify to a single DB file and then configure for multifile operation at deployment time. For more information please refer to the Operations Guide: Initiating Multi- and Single-file Backups.

New IBCONFIG Parameter

The InterBase XEU4 patch installer provided an ibconfig.orig file. This file includes the new IBCONFIG parameter of "MAX_DB_VIRMEM_USE". This parameter controls the limit of Virtual Memory use, after which database cache allocations and expansions are disallowed. The default is 90 (however, if database cache allocation requests come in before we use 90% of Virtual Memory for the process, it is allowed).

If you have not made any changes to your default "ibconfig" from a previous installation, you can copy ibconfig.orig over ibconfig and restart the server. For further details, see the parameter definition and comments in "ibconfig" file.

ADO.NET Provider for InterBase (32-bit and 64-bit)

RAD Studio now has 64-bit drivers for dbExpress (with RAD Studio XE2) which means you can use the 64-bit Ado.NET driver.

The existing 32-bit installer of Ado.NET driver has been modified and incorporates the 64-bit assemblies into the same installer. This installer is intelligent enough to install the required assemblies on the target OS platform (32-bit assemblies for 32-bit OS, 32 and 64 assemblies on 64-bit OS).

For more information, please refer to ADO.NET Provider for InterBase (32-bit and 64-bit) in the Developer's Guide.

OTW SSL TCP/IP Connection Update

If you are using OTW SSL TCP/IP connection: Starting with InterBase XEU3 release you no longer need to specify your server hostname by the IBSSL_SERVER_HOST_NAME parameter in /secure/server/ibss_config file. The new ibss_config default file included with this release has this parameter commented out, so this can be used in most cases. When the IBSSL_SERVER_HOST_NAME parameter is not set, the InterBase server will use the same hostname as used by the non-SSL TCP/IP connection.

If you do specify the hostname in the ibss_config file, you must ensure that the hostname resolves to IPv4 TCP/IP address and not a IPv6 address. One way to force a IPv4 resolution is to include your hostname in the hosts file with a valid IPv4 address. On Windows your hostname should be in the <Windows system file>\drivers\etc\hosts file.

DES Encryption Keys Backup and Restore Enhancement

Backup/Restore operations can now be restricted on any encrypted database. For more information, please refer to Encrypting Your Data in the Data Definition Guide.

OpenSSL Updated from 1.0.0a to 1.0.0d

InterBase XEU2 was upgraded from 1.0.0a to OpenSSL 1.0.0d.

For more information on using OpenSSL in InterBase XE, please reference Network Configuration in the Operations Guide, as well as Encrypting your Data in the Data Definition.

For additional information on OpenSSL please refer to: open ssl.

InterBase Direct I/O for DataBase Files

InterBase XE3 Update 4 Hotfix 1 (version 11.0.4.816) and later versions resolve the performance problem with sync/async database-write modes on Windows 2008 R2 and Windows 7 64-bit OS editions. You can still use "direct" I/O for your databases to completely circumvent the System File Cache, but you are not required to do so due to the earlier reported performance issues.

For more information, please refer to InterBase Direct I/O for DataBase Files in the Operation Guide.

InterBase 32-Bit and 64-Bit Native Binary Applications

For both the 32-bit and 64-bit editions, if you are still using dialect 1, you must migrate to dialect 3. Performance monitor tables will not work in the counters and will generate errors. For more information please reference Understanding SQL dialects in the Operation Guide.

InterBase 32-Bit Native Binary Application

The ib_install.exe is delivered with the 32-bit Edition issue. You will need to run this installer if you want to to use the 32-bit Edition on Windows.

InterBase 64-Bit Native Binary Application

  • With the 64-bit edition, you can continue to use 32-bit InterBase applications.
  • Please note that the 64-bit kit cannot be installed on a 32-bit operating system.
  • Because of InterBases focus on backward compatibility, it is easier to migrate to new editions.

The topics below cover the critical information you need to implement the 64-bit application.

Compatability Issues

  • The local and remote connections from older clients are expected to work with newer 32-bit/64-bit servers; and vice-versa.
  • IBMgr.exe and IBConsole.exe continue to be 32-bit applications. But they are expected to work with 32-bit and 64-bit servers.
  • This version supports existing ODS 12.x and ODS 13.x databases that were introduced in previous releases of InterBase.
  • You can expect to move databases between 32-bit and 64-bit kits of InterBase (with this version) as long as they support compatible ODS versions.

Client Library Name Changes for 64-Bit DLL's

The following table displays the new client library names for the 64-bit DLL's.

Library Name Location Notes
ibclient64.dll <interbase>/bin This is a new InterBase client DLL for native 64-bit applications. It is being used by 64-bit InterBase command-line tools currently, and will need to be deployed with 64-bit applications built by customers (in place of gds32.dll which is for the 32-bit target)


ibxml64.dll <interbase>/bin This is a new InterBase XML DLL for native 64-bit applications. It will need to be deployed with 64-bit applications built by customers (in place of ibxml.dll which is for the 32-bit target) if they are using the InterBase XML api.


ib_util64.dll <interbase>/bin This is a new InterBase UTILS DLL for native 64-bit applications. It will need to be deployed with 64-bit applications built by customers (in place of ib_util.dll which is for the 32-bit target).


ibclient64_ms.lib <interbase>/SDK/lib_ms Import library for building 64-bit applications targeting the ibxml64.dll.


ib_util64_ms.lib <interbase>/SDK/lib_ms Import library for building 64-bit applications targeting the ib_util64.dll.


JDBC Driver Updates for Blob/Clob Support

New interfaces have been implemented for JDBC. For more information on Blob, Clob, and other related API Interfaces, please refer to Programming with JDBC in the Developer's Guide

Stronger Password Protection

Stronger password protection on InterBase databases can be implemented with InterBase XE. This additional functionality supports a longer effective password length, resulting in stronger password protection. For more information, please refer to Implementing Stronger Password Protection in the Operation Guide

Larger Database Cache Settings for 64-bit InterBase

There is now a larger database cache setting for 64-bit InterBase. The limit for the 64-bit engine is 75 million pages, as compared to 750K pages for 32-bit engines. For more information, please refer to Various InterBase Limits in the Operations Guide

EXECUTE STATEMENT for Stored Procedures

InterBase XE now provides support for the EXECUTE STATEMENT functionality. This feature enhances the InterBase Stored Procedure language. Once this is implemented, Stored Procedure developers can embed three variations of EXECUTE STATEMENT within their Stored Procedures. The variations depend on the number of rows returned from the EXECUTE STATEMENT command. The three cases are: No rows or data returned; One row of data returned; and Variable number of rows returned.

Important: Starting with InterBase XE7 Update 1, there is a new requirement on FOR EXECUTE STATEMENT to match every item in the SELECT list with a corresponding item in the INTO list.

For more information, please refer to EXECUTE STATEMENT in the Language Reference Guide.

Database Fast Sweep

Sweeping a database is a systematic way of removing outdated records. Periodic sweeping prevents a database from growing too large. In the past sweeping slowed system performance and users disabled the automatic database sweep function because of the impact on product operations.

With the implementation of the fast sweep optimization in InterBase XE, the memory allocation issue has been mitigated. The user has the option to configure their databases for automatic sweep. For more information, please refer to Sweep Interval and Automated Housekeeping in the Operations Guide.

Table-Specific Blocking Factor

The term blocking factor is used to denote the number of records stored in a block. InterBase employs a single database-wide blocking factor that maximizes the number of rows that can be stored on a data page.

The blocking factor values for individual tables can be observed in the system columns:

  • RDB$RELATIONS.RDB$DATA_BLOCKING_FACTOR
  • RDB$RELATIONS.RDB$BLOB_BLOCKING_FACTOR

For more information, please refer to Table 6.26 - RDB$RELATIONS in the Language Reference Guide.

Larger Index Key Segment Size

With the ODS 15 databases the maximum index key size limit is increased. Now larger column data can use this for both single-byte character sets and multi-byte (such as UTF8) columns. For more information, please refer to Various InterBase Limits, Table B.1 in the Operations Guide.

New IBCONFIG Parameter APPDATA_DIRECTORY

To indicate the above "Program Data" location value to all InterBase applications (and database engine), a new IBCONFIG parameter value for APPDATA_DIRECTORY (new parameter in InterBase XE3) is now added automatically at the time of install. This value provides the absolute path of the above "Program Data" location. See the file <interbase>/ibconfig file for further details.

  • Program Data Location
  • The "Program Files" location will be used primarily for files which are required read only.
    • Directory: System "Program Files" (varies for 32-bit or 64-bit Windows)
      • ibconfig (this is where you will deliver an older customized ibconfig file if you are migrating from an older InterBase version)
      • binaries including server, graphical and command-line tools libraries
      • SDK
      • interbase.msg
      • Doc subfolder with PDF and HTML docs
      • Product EULA (License.txt and oss_license_notice.txt)
  • Windows Registry Changes from Borland to Embarcadero
  • InterBase uses the Windows Registry to store information for a particular installation of InterBase server-based products. Due to its Borland legacy, previous InterBase versions had stored this information under the Windows Registry key "HKEY_LOCAL_MACHINE\Software\Borland\InterBase\Servers\".
  • InterBase XE3 now uses the Windows Registry hierarchy under "HKEY_LOCAL_MACHINE\Software\Embarcadero\InterBase\Servers\". The InterBase server, guardian, client library, IBMgr, and IBConsole programs have been updated to support this change.
Retrieved from "https://docwiki.embarcadero.com/InterBase/XE7/e/index.php?title=Previous_Releases&oldid=22277"