InterBase XE7 Readme

From InterBase

Go Up to InterBase Readme


November, 2014

The InterBase XE7 introduces several major new feature as well as multiple updates and enhancements. See New Features for a complete list and explanation of each feature.

This file contains important information that may not appear in the online Help. Please read this file in its entirety.

Note: InterBase ToGo and IBLite applications are available through XE3 Editions.

Important: For the latest version of this document, please visit http://docs.embarcadero.com/products/interbase/.

The InterBase XE7 Readme covers the following sections:

New Features

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

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

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

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

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

  • Mobile Platforms
  • New Connection Property for InterBase JDBC Apps
  • Display Timestamp

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

  • GLOBAL TEMPORARY TABLE SUPPORT

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.

  • Call Home Feature
  • ODBC Driver Transition

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.

Sample applications are provided in the <interbase>/examples location for all the SPB parameters listed above. start_dump.c exercises the online/incremental dump operations. ib_archive.c exercises the Journal Archive related operations.


Migration Issues for InterBase XE7

  • It is important to note that older clients (old IBConsole) will surface exceptions when connecting to newer ODS 16 databases since they will encounter data type not defined as INTEGER. The workaround is to install the newer IBConsole and connect with older and newer InterBase servers. The newer IBConsole is backward compatible for this purpose.
  • The InterBase Lock Table size need to be increased by changing the IBconfig parameter as every entry occupies more room.
  • InterBase XE7 is released with ODS 16. The new engine only supports ODS >= 13. So with this change, all supported platforms will support the same ODS versions (13 to 16).
  • Some 64bit UDF libraries built with older Visual Studio versions (2005 and earlier) have been reported to not work with InterBase XE7. If you have any old UDF libraries, please do extra testing of these with the new InterBase version. Or, rebuild your UDF 64-bit libraries with the latest Visual Studio versions.
  • The new keyword ROW is "reserved" as a SQL keyword token.

Migration Issues for InterBase XE3

Windows Registry and Program Files Changes

InterBase XE3 introduces changes for better Windows compatibility. InterBase XE3 allows default installation of the product under the "Program Files" location and no longer uses the "Borland" subkey in the Windows Registry hierarchy. It now uses the "Embarcadero" subkey to track instance specific information. We strongly advise and encourage you to migrate your applications to the new environment as soon as possible.

  • Program Files Install Location
  • InterBase versions since 2009 installed the product in a different location other than the default Windows location of "Program Files". This was because of Windows UAC guidelines that put restrictions around applications without administrative privilege from writing under the "Program Files" file system folder. InterBase XE3, for server-based editions, now conforms to the Windows Application compatibility guidelines. The default install location has changed from C:\Embarcadero\InterBase to C:\Program Files\Embarcadero\InterBase.
  • Program Data Location
  • InterBase XE3 now delivers the program data files under %ALLUSERSPROFILE%\Embarcadero\InterBase directory. For each individual instance of an install, a folder is created under this and all files requiring write access are delivered here. For example if you install InterBase XE3 with the defaults, and get 'gds_db' instance, your InterBase write location and files include the following.
    • Directory: %ALLUSERSPROFILE%\Embarcadero\InterBase\gds_db
    • Files:
      • admin.ib (this is where you will deliver an older admin.ib file if you are migrating from an older InterBase version)
      • license/ (this is where you will deliver InterBase license files)
      • Examples subfolder structure with all related files
      • OTW SSL related files under "secure" subfolder
      • runtime created files such as interbase.log, *.lck, *.env

Migration Issues

  • Be sure to back-up all databases, including the security database, before uninstalling the previous version.
  • We recommend that you upgrade your InterBase clients to 10.0.0.292 or above if you are targeting a SUSE 11 SP1 (or above) server. There are known problems with older clients waiting for events from a SUSE 11 SP1 server.
  • Back-up the ibconfig file if it has been customized.
  • This version creates new databases with ODS version 15.
  • Please only provide 64-bit UDF libraries for a 64-bit edition, if any, of InterBase. Note that the 64-bit server will not be able to load any 32-bit UDF libraries that you may have. The UDF library that is provided (OOTB, ib_udf) is already built for 64-bit and is installed with the product.
  • InterBase XE increased the number of records that can be stored in a table. The current count has 32-bit limitations. If you want to get a count of the number of record values beyond 32-bit, you need to take the following steps:
    • If a table does have more than 2G rows then the developer must code a CAST(COUNT(*) AS NUMERIC(18,0)) to get a 64-bit count.
  • InterBase XE implemented stronger password protection. If you have older InterBase clients (locally or from remote systems) communicating with this installation, please note the following while upgrading your system to InterBase XE3:
    • If you have an existing user authentication database (from previous InterBase versions), use that database file (copied to the InterBase XE folder) and authentication for local/remote clients will work correctly.
    • If you use the new admin.ib from InterBase XE, note that this database has "SHA-1" strength passwords (by default). If you want to continue using the (weaker) DES password algorithm (previous InterBase releases), use the ALTER DATABASE command referred to in the Stronger Password Protection topic.
    • If you want to use "stronger password length" (provided in InterBase XE), you will need to recreate your user accounts AND install the new InterBase clients in remote machines connecting to this InterBase XE server. This is because the "old" InterBase clients are not capable of computing the "SHA-1" passwords and thus pass in the "DES" strength passwords which in turn do not match what the InterBase XE server expects. This gives you the error "Your user name and password are not defined..."
  • InterBase XE updated SSL parameter names. The old OTW client properties have been replaced by new OTW properties. Please refer to the Operations Guide "Setting up OTW Encryption" and Table 5.2 located in Chapter 5.
Restoring database results in the error "unassigned code"
When restoring a database with InterBase XE, get the error unassigned code. With databases with a long lineage or databases backed up with InterBase 2009 and restored with InterBase XE, each case has different metadata security settings. So when selecting a system table (for example: RDB$RELATIONS) you get the error message: no permission for read/select access to table RDB$RELATIONS by user SYSDBA.
This error occurs with databases which have these criteria
  • Originally created with a version of InterBase prior to InterBase 6.5.
  • Backed up with a version of InterBase prior to InterBase 2009.
  • Readmeta.sql has not been previously applied.
This behavior is exhibited due to stricter enforcement of meta data rights in InterBase XE during the restore of a database.
Solution
To resolve this problem execute readmeta.sql against your database before you back it up. readmeta.sql may be found in \examples\security. You can execute readmeta.sql against your database using isql or IBConsole.
Explanation:
The problem occurs with databases that have a long lineage. The two cases are (1) a database has a restore history of IB6->IB7->IB2007->IB2009->IBXE; and (2) a database backed up and restored as IB2009->IBXE. Each case has different metadata security settings. The first instance never had metadata security because it originated from IB6. However with the second instance, it was created (not restored) by IB2009 with a full complement of security privileges for all system tables.
With the first case, the database was backed up and restored and with each succeeding release, the new release would install privileges for the new system tables in that release (think RDB$USERS, RDB$ENCRYPTIONS, RDB$ROLES, etc.). But it could not alter the original system tables because it had no way of knowing if the database owner had already altered their security privileges. For example, a user might have revoked all privileges to RDB$TRIGGERS and RDB$PROCEDURES to conceal their trigger and stored procedure code.
Also, in the first case, a SYSDBA may have run readmeta.sql years ago and refined the metadata from that baseline to a custom security profile. InterBase cannot override that customization by automatically resetting it after the XE restore. InterBase XE ca not assume that every database it restores should unconditionally install the default metadata privileges because it does not know the history of individual databases.
So it is recommended to run readmeta.sql, which sets the default or starting point for configuring it the way you want it. This advice is independent of whether you are migrating to XE.
Example using isql:
isql "path to database"
-user sysdba -password masterkey -i readmeta.sql
Executing readmeta.sql with IBConsole
  1. Connect to your database with IBConsole.
  2. Tools | Interactive SQL ...
  3. Query | Load Script, select readmeta.sql, click OK.
Error: No Permission for read/select access to table RDB$XXXX by user SYSDBA
Databases originally created before InterBase 6.5 may have the error: no permission for read/select access to table RDB$XXXX by user SYSDBA with InterBase XE.
Solution:
InterBase XE enforces tighter meta data security and this error may result from doing meta data operations on databases originally created with versions of InterBase prior to version 6.5. Meta data operations involve requesting information about system objects such as listing system objects or updating them and using the Performance Monitor.
To resolve this error you need to perform two similar operations. The first operation grants rights to system tables. To do so, execute readmeta.sql from the examples\security folder in your InterBase install directory. You can execute readmeta.sql against your database using isql or IBConsole.
Example using isql:
isql "path to database"
-user sysdba -password masterkey -i readmeta.sql
Executing readmeta.sql with IBConsole
  1. Connect to your database with IBConsole.
  2. Tools | Interactive SQL ...
  3. Query | Load Script, select readmeta.sql, click OK.
Second, you need to grant rights to system temporary tables if you are going to do performance monitoring. Due to potential security concerns, most installations will want to grant rights for system temporary tables only to sysdba and the database owner, which is what is presented below. If you wish for all users to be able to view system temporary tables, modify this example to GRANT TO PUBLIC. Some installations will want only specific users to have rights, in which case a more customized script may be needed.
To grant rights for system temporary tables, save the following as a text file, then execute it the same as readmeta.sql above.
create procedure granttmp as
  declare variable stmt varchar(1024);
  declare variable ownername varchar(66);
  declare variable tablename varchar(66);
begin
  select rdb$owner_name from rdb$relations where rdb$relation_name = 'RDB$RELATIONS'
  into :ownername;
for select rdb$relation_name from rdb$relations where rdb$system_flag>0 and rdb$relation_name starts with 'TMP$' into :tablename do
begin
  stmt = 'grant all on ' || tablename || ' to sysdba';
  execute statement stmt;
  stmt = 'grant all on ' || tablename || ' to ' || ownername;
  execute statement stmt;
end
end;
execute procedure granttmp;
drop procedure granttemp;
commit;
exit;

Known Issues

  • Issue: GROUP COMMIT is now enabled once again with the corruption issue resolved. It was disabled at run time in InterBase XE3U4. Please retest in your test environments where you have enabled database GROUP COMMIT.
  • It is important to note that older clients (old IBConsole) will surface exceptions when connecting to newer ODS 16 databases since they will encounter data type not defined as INTEGER. The workaround is to install the newer IBConsole and connect with older and newer InterBase servers. The newer IBConsole is backward compatible for this purpose.
  • IBConsole Performance Monitoring provides wrong values for ODS 16, dialect 1 database.
Workaround: There is no workaround for ODS 16 dialect 1. Use dialect 3 database to test IBConsole Performance Monitoring.
  • Service API support to restore to a specific major ODS version with SPB parameter isc_spb_res_ods_version_major does not work.
Workaround: Only use 'gbak' command-line tool to test this for now. The next beta update will have a fix for this problem.
  • The License Registration Wizard brings up product description as "InterBase XE3 Product Registration".
Cause: This is because the beta build is still compatible with InterBase XE3 license SKUs. In a future beta build, we will change this to use new product SKUs and the description in the license registration tool will change then.
  • The GROUP COMMIT feature has been disabled in InterBase XE3 until the stability issues have been resolved.
  • The 16-bit UNICODE character sets UNICODE_LE and UNICODE_BE only work for Server character sets. These character sets cannot be used as a client character set. If your client needs full UNICODE character support, please use UTF8 instead of UNICODE_LE and UNICODE_BE for the client character set (aka LC_CSET). A client can use the UTF8 (or other native) client character set to connect with a UNICODE database.
InterBase XE3 supports no defined UNICODE collations in this release. The default collation is binary sort order for UNICODE.
  • Windows Error Reporting (WER) dialog pops up intermittently if and when an InterBase server crashes.
Resolution: We are working on fixing any crashes that we are aware of. In the meantime you can disable the Windows Error Reporting dialog from popping up by modifying the Windows Registry thus. Set the registry attribute HKEY_CURRENT_USERS\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI value to 1 to disable. This is as per recommendation of MSDN article http://msdn.microsoft.com/en-us/library/bb513638(VS.85).aspx. We may address this configurable option from within ibserver.exe in future builds by informing WER to disable this only for InterBase server binary.
  • Issue: Hyperthreading: InterBase supports Hyperthreading only on 32-bit Edition on Windows, and on older Intel CPU architectures. It is a known issue that the feature does not work on some of the latest CPU architectures. If your InterBase deployment has licensed less CPU cores than is available on the system, you can customize your installation via the CPU_AFFINITY setting in IBConfig to choose the desired CPU cores for InterBase.

Additional Resources

Embarcadero Technologies Technical Support

If you have a valid maintenance contract with Embarcadero Technologies, the Embarcadero Technical Support team is available to assist you with any problems you have with our applications. Our maintenance contract also entitles registered users of Embarcadero Technologies products to download free software upgrades during the active contract period. Evaluators receive free technical support for the term of their evaluation. We encourage you to visit the Support section of our Web site.

Embarcadero Technologies on the Web

Evaluators receive free technical support for the term of their evaluation. To download evaluations of Embarcadero Technologies products or to learn more about our company and our products visit us at http://www.embarcadero.com/.

Topics

See Also

Retrieved from "https://docwiki.embarcadero.com/InterBase/2020/e/index.php?title=InterBase_XE7_Readme&oldid=27503"