Previous Releases

From InterBase
Jump to: navigation, search

Go Up to What's New


Contents

Previous Releases

Listed below are the new features from earlier releases:

XE7

InterBase XE7 Update 7

Please, see the bugs fixed in XE7 Update 7 listed in Resolved Defects.

This release does not include major features.

InterBase XE7 Update 6

Please, see the bugs fixed in XE7 Update 6 listed in Resolved Defects.

This release does not include major features.

InterBase XE7 Update 5

Please, see the bugs fixed in Update 5 listed in Resolved Defects.

This release does not include major features.

InterBase XE7 Update 4

Please, see the bugs fixed in Update 4 listed in Resolved Defects.

This release does not include major features.

InterBase XE7 Update 3

Please, see the bugs fixed in Update 3 listed in Resolved Defects.

This release does not include major features.

InterBase XE7 Update 2

This release contains the following new features and enhancements to existing features:

InterBase XE7 Update 1

This release contains the following new features and enhancements to existing features:

InterBase XE7

Introduces many new features and enhancements to further extend the capabilities of InterBase. A few of the new or enhanced features are highlighted below:

  • Change Views: Allows you to quickly answer the question: "What data has changed since I last viewed it?"
  • Linux kits: The Linux kits, 32-bit and 64-bit are now available in the InterBase XE7 release.
  • Performance Enhancements: These enhancements include improved SMP performance, distinguished dump enhancements, and improved Read Committed (RC) Transaction Processing.
  • ODS Changes: New ODS version 16 was introduced to support Change Views and new Index Managers for better performance. You can also now restore your database backup file to an older supported ODS version; supported older ODS versions include 13 and 15.


Sandboxing with InterBase ToGo for Mac OS X

You can sandbox your RAD Studio Delphi/C++ database applications for Mac OS X. See App Sandboxing with InterBase ToGo for Mac OS X for more information about sandboxing of InterBase applications with RAD Studio.


Updated Workflow for ToGo Edition

This release includes a ToGo Trial Edition that will expire 30 days after registration. See InterBase ToGo Trial Licenses for licensing information.

Change Views Updates

This release includes the following changes in Change Views:

DROP SUBSCRIPTIONS
SQL Extensions

DROP SUBSCRIPTIONS

The ability to drop subscriptions was added to Change Views for the InterBase XE7 Update 1 release. The syntax for DROP SUBSCRIPTION is:

DROP SUBSCRIPTION <subscription_name> [RESTRICT | CASCADE];

To eliminate interest in observing a set of change views, a subscription must be dropped.

  • If RESTRICT is specified, then a check of existing subscribers is performed.
  • If there are subscribers, then an error is returned without dropping the subscription.
  • If CASCADE is specified, then all subscribers of this subscription are also dropped.
  • If neither RESTRICT nor CASCADE is specified, then RESTRICT is assumed.

SQL Extensions

InterBase SQL provides support for Change Views with the IS [NOT] {CHANGED | INSERTED | UPDATED | DELETED} clause.

SET SUBSCRIPTION sub_employee_changes ACTIVE;
SELECT EMP_NO, DEPT_NO, SALARY FROM EMPLOYEE WHERE SALARY IS UPDATED;
EMP_NO     DEPT_NO           SALARY
--------   ----------        ----------
109        600               75000

In the example above, we see that EMP_NO=37 employee's department reassignment is not returned since he received no compensation adjustment for a lateral move. The IS CHANGED clause will detect the modification of a column due to any kind of SQL operation.

IBConsole Updates

This release includes several significant updates for the IBConsole feature:

Start Here Tab

A "Start Here" tab opens when IBConsole is accessed. This tab contains a collection of videos, user guides, and tutorials. It also gives you access to the InterBase website that includes an overview, a description of what's new, frequently asked questions, testimonials, and tutorial videos.

IBConsole Database Pane

The pane located in the bottom left corner lists the most frequently used databases. Click the database name link to connect to that database.

IBConsoleDatabasePane.png

Change Views Subscription Support

IBConsole now supports a subscription editor. This subscription returns data that have changed since the prior transaction in which the implicit view was observed. This allows you to see what data has changed since the last time you viewed it.

  • Right click on a database subscription field and click Create to gain access to the Subscription Editor dialog.
IBConsoleSubscription.png



Change Views Feature

The Change Views feature uses InterBase multigenerational architecture to capture changes to data. This feature allows you to quickly answer the question: "What data has changed since I last viewed it?"

Previously it involved triggers, logging, and/or transaction write-ahead log scraping. This was time-consuming for the developer and affected the database performance for a certain transaction load or change volume. Now with Change Views, there is no performance overhead on existing transactions because it maintains a consistent view of changed data observable by other transactions.

The Change Views™ feature uses InterBase multigenerational architecture to capture changes to data. This feature allows you to quickly answer the question: "What data has changed since I last viewed it?" Previously it involved triggers, logging, and/or transaction write-ahead log scraping. This was time-consuming for the developer and affected the database performance for a certain transaction load or change volume. Now with Change Views, there is no performance overhead on existing transactions because it maintains a consistent view of changed data observable by other transactions.

The Change Views mechanism is not dependent on its own underlying data, but is based on data already stored for existing base tables or views derived from base tables. This implicit view mechanism is temporal based and returns data that have changed since the prior transaction in which the implicit view was observed.

Change Views can be subscribed to in order to view data that has changed across database connections. The effect is a long-lived transaction spanning multiple database connections.

  • Specifically, the subscription tracks all row inserts, updates, and deletes to one or more tables at a column-level granularity over a disconnected, extended period of time.
  • The InterBase SQL query language is modified to search on columns where data has changed since the prior observation.
  • These data changes are tracked at a column granularity.

Linux 32-bit and 64-bit

The Linux kits, 32-bit and 64-bit, were introduced in the InterBase XE7 release. New Linux builds (12.0.0.124) are available for InterBase XE7.

License Manager

The License Manager changed from InterBase XE3 to InterBase XE7.

Performance Enhancements

  • Improved SMP Performance: The performance of multiple reads and writes improved for this release.
  • Distinguished Dump: "Incremental Dump" in InterBase XE3 required the database server to read all pages from the database file, but only write the pages that had been modified to the target database dump file. With the implementation of a tracking system in XE7, only those pages that need updating since the last dump would be fetched. This provides instantaneous updates to the target. There can only be 1 "Distinguished Dump" per source database.
The choice of a "distinguished dump" is as follows:
  • The first "dump" on the source database file will be a "distinguished dump"; all further dump targets are "normal dump" targets.
  • Should the "first" dump be made online and thus sever its link to the source database, the next "dump" to be incrementally updated will now become the "disinguished dump".
  • Improved Read Committed (RC) Transaction Processing for large (OIT - OAT) transaction gap: In XE3 and prior versions, RC transaction processing can grind to a halt as the "housekeeping" (OIT - OAT) gap grows larger. This usually does not happen unless the database has disabled automatic internal sweep function or the housekeeping gap is set to a very high value. This gap is usually in the 10's of millions for the performance degradation to be noticed. The OIT usually sticks after an abnormal server termination or a transaction savepoint is discarded because it has grown too large trying to track changes of a running transaction and that transaction ultimately rolls back.
    • With XE7, RC transactions perform much faster in the above scenario. In one of our tests to count 1 million records in a table, in XE3 the test took 14.48 seconds. In XE7 the time to execute the query was 0.97 seconds. The performance of the RC transaction is now on par with Snapshot mode transactions. Just to note, Snapshot transactions did not exhibit any slowdown in earlier versions.
  • Quicker transaction creation: With XE7, you can create more transactions/sec than with prior InterBase versions.

Performance Monitoring Counters

The performance monitoring counters have been scaled up from 32-bit to 64-bit values. It includes all data stored on tables within the database. IBConsole has been updated for this release.

There are some ODS-related differences to be aware of:

  • ODS <= 15 will continue to have 32-bit INTEGER counters as before (for both dialect 1 and dialect 3 databases).
  • ODS >= 16 will have the counters defined as "double precision" data type for dialect 1 databases.
  • ODS >= 16 will have the counters defined as "NUMERIC(18,0)" data type for dialect 3 databases. As you know, by default, any new database is created as ODS 16, dialect 3.

For dialect 3, the Performance Monitoring data counters have been updated to 64-bit Integer type. Since dialect 1 cannot support 64-bit Integer type, a 64-bit Integer type will be internally converted to type "double precision" as it is the same size (8 bytes) and will also accommodate the large values for 64-bit addresses and counter values.

The best way to identify the differences between dialect 1 and dialect 3 is to check field definitions for the result of the SQL query against your database. So if you ran the following query: SELECT RDB$FIELD_NAME FROM RDB$FIELDS WHERE RDB$FIELD_LENGTH=8 AND RDB$FIELD_TYPE=16;, the results would show as follows:

  • FIELD_TYPE 16 indicates NUMERIC(18,0) and will be set in dialect 3.
  • Dialect 1 database will have none of this field type since it will be double.

Backward Compatibility

With the support of 64-bit Integer data counters for Performance Monitoring, backward compatibility is maintained for the new server working with ODS 15 databases where such counters are 32-bit Integers.

To do this, enable gpre with the "-ods <major_ods_number>" command-line option that allows GPRE to limit its parsing of GDML/ESQL programs to relations/tables that are only valid until that major ODS.

 gpre [-ods <number>] ... <foo.e>
 For e.g.:
 gpre -ods 15 tmp.e

Partial Segment Selectivity

InterBase currently maintains a single selectivity value per index (whether single or composite key). The values are stored in descending order and track information on how many duplicates exist in the whole index – but only first level. However, there are times when it would be helpful to have information on lower levels. InterBase XE7 can now track this. Changes have been implemented for a new ODS (version 16) that allows gathering segment-specific selectivity to be stored and retrieved from RDB$INDEX_SEGMENTS.RDB$STATISTICS.

For example: an index exists on columns F1, F2, and F3, and the query provides a conjunct (condition) on only the first two columns F1 and F2. The optimizer can use a value that only reflects the underlying selectivity of the columns F1 and F2 instead of F1+F2+F3 and then make a decision on whether to use the index or not.

You will see certain queries run faster, but will not see any change in data.

64-bit Transaction IDs

InterBase XE3 supported only (signed) 32-bit Transaction IDs. This allowed only 2 Billion transactions to be executed in a database before the transaction ID needed to be reset using a backup/restore procedure. This was limiting for 24/7 databases and for those who had transaction-intensive application suites.

InterBase XE7 scales transaction IDs to 64-bit (actual 48-bit) so databases now can accommodate more transactions without the old limitations. It limits itself to 48-bit, as to be aware of future transaction ID growth.

The transaction limits now work as follows:

  • Databases with ODS <=15 need to be backed up and restored before they hit the 2-billion transaction ID limit.
  • Databases with ODS >=16 can continue to be online beyond 2-billion transactions since they support 64-bit transaction ID. A benefit of this is you can have your databases online to service your applications closer to a 24/7 scenario without the need to back up/restore due to this earlier 32-bit limit.
  • 64-Bit Conversion.
  • This project assumes conversion to 64-bit (more likely 48-bit) transaction IDs with the assumption that they could not be exhausted in a reasonable timeframe.
  • For example, a database with a 4KB page size could run continuously in excess of 10,000 tps for 100 years with a 48-bit transaction ID.

ODS Changes

Allowing a Database Backup to be Restored to a Particular Older ODS Version

A database restore operation automatically creates a database with the latest ODS version (as supported by the engine). However, there are situations where the developer may need to restore an older version:

  • To enable the same database file to be deployed to other compatible-database engine versions.
  • To provide a workaround for hard-to-resolve current ODS bugs.
  • To test performance-sensitive operations between current ODS version and older ODS versions by using a single server/engine to restore multiple copies of the same database (one per ODS) and then running the queries against each one of those database files. For example, to test certain versions of index managers released in newer ODS versions.

You can use this implementation in several different ways:

IBConfig Parameter

DATABASE_ODS_VERSION. Allows a major ODS version number to be specified server-wide. A newly-created database or one restored using GBAK is restored with this ODS version. It now has full support for new Performance Monitoring artifacts for 64-bit integer counters with full backward compatibility with older ODS databases.
The IBConfig file has a new parameter for this action as documented below.

#DATABASE_ODS_VERSION 16 ##Platforms: All ##Version: starting in InterBase XE7 ##The database server/engine will automatically create/restore ##databases to this major ODS version number, if specified. ##Valid ODS major versions are in the range 13 to 16 ##Default major ODS version is the latest version supported by the product

DPB Parameters

Allows the application to selectively create/restore databases using a new DPB parameter isc_dpb_ods_version_major.

GBAK Restore Option

"-ods_version <n>" where <n> is a supported major ODS version. The target database engine will have its own allowed major ODS version list. XE7 will allow ODS versions 13 through 16.
A new GBAK restore option is available for restoring a specific major ODS version. When this option is specified at restore time, it overrides the server-side IBConfig setting DATABASE_ODS_VERSION.
gbak -r employee.gbk emp15.ib -ods_version 15 -user sysdba -pass masterkey
gbak -c employee.gbk emp16.ib -ods_version 16 -user sysdba -pass masterkey
gbak -service localhost:service_mgr -r <path>/employee.gbk <path>/emp13.ib -ods_version 13 -user sysdba -pass masterkey

OpenSSL Upgrade

OpenSSL libraries included in InterBase XE7 are upgraded from version 1.0.0d to version 1.0.1i with Security Vulnerability fixes. OpenSSL is used for Encryption and OTW/SSL features in InterBase.

For more information on using OpenSSL in InterBase XE7, 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: ssl.

Services API Support for Online Dump and Journal Archive Operations

Online Dump and Incremental Dump

Database Online Dump and Incremental Dump were, before this release, only supported as DPB options. It was not available as a Services API option, which made it difficult for connectivity layers such as IBX to identify this "backup" functionality differently from other "Services API"-aware backup functionality. Services API now supports online dumps and incremental dumps.

The following lists the features for this function:

  • The task isc_action_svc_dump has been added with the purpose to dump a database to a file. This is equivalent to gbak -d.
  • Use the cluster identifier isc_action_svc_dump to request that the Services Manager perform a dump operation. This is a programmatic method invoking the gbak tool as a thread in the ibserver process. You must specify the path of the database primary file, and the path of the dump output file or files. Paths of dump files are relative to the server. Because the Services Manager executes dump tasks on the server host, the Services Manager reads and writes dump files on the server host. The Services Manager also creates files in the context of the server.
  • The following Online Dump and Incremental Dump actions have been added via isc_action_svc_dump:
Action Argument Purpose Argument Length Argument Value
isc_action_svc_dump isc_spb_dmp_create Request to execute an Online Dump operation and create an online dump database from a source database. This is passed as a standalone option value to isc_spb_options. This operation is equivalent to the "gbak -dump" command. 0 0
isc_action_svc_dump isc_spb_dbname Path of the primary file of the database, from the point of view of the server. 2 bytes + string String
isc_action_svc_dump isc_spb_dmp_file Path of a dump output file; you can specify multiple output files. 2 bytes + string String
isc_action_svc_dump isc_spb_dmp_overwrite Overwrite existing dump file; absence connotes incremental update of existing dump file. This operation is equivalent to the "gbak -overwrite_dump" command. This parameter should be provided just by itself in the SPB byte array. This is an optional argument. 0 0

Note: To create Online and Incremental database dumps without requiring a database, and by only using Service API, use the new SPB parameter isc_spb_dmp_create. This is passed as a standalone option value to isc_spb_options and is equivalent.

Journal Archive Management Actions

The Journal Archive Management actions were, in the past, only supported from the following command-line tools:

  • GBAK supports Archive Database, Archive Journals, and Archive Recover actions.
  • GFIX supports Archive Dumps and Archive Sweep actions.

Previously, no Service API support existed that applications could invoke. However, now by using the cluster identifiers isc_action_svc_backup, isc_action_svc_restore, or isc_action_svc_properties, you can request that the Services Manager perform various operations on InterBase Journal Archives.

This is a programmatic method to invoke the gbak tool as a thread in the ibserver process. You must specify the absolute full path of the database primary file, and recovery related database files. Because the Services Manager executes archive management tasks on the server host, the Services Manager reads and writes journal archive location files on the server host. The Services Manager also creates files in the context of the server.

  • The following Services API Journal Archive Management Actions have been added:
Action Argument Purpose Argument Length Argument Value
isc_action_svc_backup isc_spb_bkp_archive_database Request to execute an Archive Database operation and create an archive database copy from a source database. This is passed as a standalone option value to isc_spb_options. This operation is equivalent to the "gbak -archive_database" command. 0 0
isc_action_svc_backup isc_spb_dbname Path of the primary file of the database, from the point of view of the server. This database will be copied by the database engine to the Journal Archive location defined for that database using CREATE JOURNAL ARCHIVE command. 2 bytes + string String
isc_action_svc_backup isc_spb_bkp_archive_journals Request to execute an Archive Journals operation and copy journal files for the source database to the journal archive directory location. This is passed as a standalone option value to isc_spb_options. This operation is equivalent to the "gbak -archive_journals" command. 0 0
isc_action_svc_backup isc_spb_dbname Path of the primary file of the database, from the point of view of the server. The journal files for this database will be copied by the database engine to the Journal Archive location defined for that database using CREATE JOURNAL ARCHIVE command. 2 bytes + string String
isc_action_svc_restore isc_spb_res_archive_recover Request to execute an Archive Recover operation and recover from a database archive in the journal archive directory location. This is passed as a standalone option value to isc_spb_options. This operation is equivalent to the "gbak -archive_recover" command. 0 0
isc_action_svc_restore isc_spb_bkp_file Path of the database in the Journal Archive location, from the point of view of the server. The database file mentioned will be used as the source database to recover from followed by recovering data from associated journals from the same archive location. 2 bytes + string String
isc_action_svc_restore isc_spb_dbname Path of the database file to restore to (or create), from the point of view of the server. The newly-restored database once fully recovered will be set to "read_only" mode and can be brought back online later. 2 bytes + string String
isc_action_svc_restore isc_spb_res_archive_recover_until This is an optional argument for Point-in-time-recovery; this operation is equivalent to "gbak -until <timestamp>" command. Argument value is string indicating Timestamp format. Accepted Timestamp string format detailed in Embedded SQL Guide (EmbedSQL.pdf) chapter "Working with Dates and Times", section "Formatting Dates for Input".

For e.g. "2006-08-21 18:08:15".

2 bytes + string String
isc_action_svc_properties isc_spb_prp_archive_dumps Request to execute an Archive Dumps operation to set a limit of database dump versions in the journal archive directory location. This operation is equivalent to the "gfix -archive_dumps <n>" command. 4 bytes Unsigned 32-bit integer value indicating number of dump files to maintain.
isc_action_svc_properties isc_spb_prp_archive_sweep Request to execute an Archive Sweep operation to sweep (delete) database dump files that have a sequence number less than the provided value in the journal archive directory location; the sweep also deletes associated journal files for those database dump files. This operation is equivalent to the "gfix -archive_sweep <n>" command. 4 bytes Unsigned 32-bit integer value indicating sequence number below which to sweep database dump files.

XE3

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 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 2017 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.