Following are the system requirements for installing and running InterBase XE 32-bit and 64-bit Native Binary applications on Windows.

System Area	Requirement
Platform	Microsoft Windows 32-bit operating systems:   Microsoft Windows Vista (32-bit)   Microsoft Windows Windows 7 (32-bit)   Microsoft Windows XP (SP3)   Microsoft Windows 2008   The 64-bit Edition can only be installed on:   Microsoft Windows Vista 64   Microsoft Windows Windows 7 (64-bit)   Microsoft Windows 2008 R2 (64-bit)
Processor	Microsoft Windows: Intel x86 or x86-64
JDK Compatibility	All platforms: JDK 6
Hard disk space	44 MB for compact installation 56 MB for full installation (includes PDF help files)

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 Operations Guide.

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.

• 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 InterBase’s 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.

      Migration Issues

• Be sure to back-up all databases, including the security database, before uninstalling the previous version.
• Back-up the ibconfig file if it has been customized.
• This version creates new databases with ODS version 15 to resolve some issues with index management and concurrent data updates.
• 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.

    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.

    Known Issues

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

    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 ibclient64.dll.
ibxml64_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.

New interfaces have been implemented which support the following:

JDBC Name	InterClient Name	Exceptions/Comments
java.sql.Blob	interbase.interclient.Blob	For all API the parameter pos is ignored and assumed to be 1, hence the complete BLOB is returned. For example in the method OutputStream setBinaryStream(long pos) the parameter pos is ignored. The same is true for all other methods which take the "pos" parameter. public long position(byte[] pattern, long start) and public long position (java.sql.Blob blob, long start) are not supported.
java.sql.Clob	interbase.interclient.Clob
java.io.inputStream	interbase.interclient IBBlobInputStream	Special implementation of the java.io.inputStream for InterBase Blob (and Clobs). Use the read() methods from this stream to access the underlying data.

The following methods have been implemented in this release:

In the java.sql.PreparedStatement class

• public void setObject (int parameterIndex, Object x) now works when parameter x is of type java.io.Inputstream.
• All variations of the setCharacterStream () method are implemented
• All variations of the setAsciiStream() and setBinaryStream() methods are implemented
• all variations of method setBlob() and setClob() are implemented.
• Method isClosed() is implemented.

In the java.sql.Result class

• All variations of the getCharacterStream () method are implemented
• All variations of method getBlob () and getClob() are implemented

This release implements stronger password protection on InterBase databases to comply with password requirements from the Payment Card Industry - Data Security Standard (PCI DSS). This additional functionality supports a longer effective password length, resulting in stronger password protection.

Requirements/Constraints

• This design supports server-wide user authentication as manifested by the USERS table of the security database, configured with the IBCONFIG.ADMIN_IB property parameter, which defaults to the file admin.ib.
• The design also supports EUA databases. As with the non-EUA databases, it also has to be explicitly enabled by the owner/administrator. Please note that the USERS table in admin.ib has RDB$USERS as the counterpart in EUA databases; so the earlier references have to be compatible with EUA database references.
• For EUA databases, the database metadata upgrade to 13.2 is automatic (for ODS 13.x databases); the database owner does not have to create the PASSWORD_DIGEST domain or modify the RDB$USERS table explicitly to set 'DES-CRYPT' for existing user accounts. The explicit actions are required only for admin.ib since the user account table on that database is a user table and not a system table.
• A plaintext password length of 32 bytes is supported in this release, up from 8 bytes in earlier versions of InterBase.
• An updated version of IBConsole is present in the kit. This version does not show the “Default” buttons in the database/server login screens.
• A batch script (changepassword.bat) is now provided in the /bin directory to update the SYSDBA account password post-install.

        Getting Started

The DES-CRYPT password algorithm has been replaced with a modern cryptographic hash function that is more widely accepted by organizations in private industry and government. The design uses SHA-1, which generates a fixed length 160-bit hash.

1. Before starting, it is strongly recommended that you backup your old admin.ib from the current installation before installing the new InterBase. This allows you to restore it, if needed.

2. If you are upgrading to a newer version you may want to continue using your admin.ib from an earlier InterBase. If so, enable stronger password protection on that admin.ib by using the following SQL commands after IB has been installed on the server:

isql admin.ib -user SYSDBA -pass xxxxxxx
sql> ALTER DATABASE SET PASSWORD DIGEST 'SHA-1';
sql> CREATE DOMAIN PASSWORD_DIGEST AS VARCHAR(16) CHARACTER SET ASCII;
sql> ALTER TABLE USERS ADD PASSWORD_DIGEST PASSWORD_DIGEST;
sql> UPDATE USERS SET PASSWORD_DIGEST = 'DES-CRYPT';
sql> COMMIT;

NOTE:   If it is a completely new installation of InterBase you do not need to run the SQL commands.

The ALTER DATABASE command can only be run by the database owner or SYSDBA. This command modifies RDB$DATABASE.RDB$PASSWORD_DIGEST to the string value "SHA-1". This means that all new password hash generation for new or existing user accounts in the USERS table will use the SHA-1 hash function.

The password hash function can be reset to DES-CRYPT using the same DDL:

ALTER DATABASE SET PASSWORD DIGEST 'DES-CRYPT';

The admin database is now prepped so that new user accounts or modifying the password of existing accounts will generate SHA-1 password hashes against plaintext passwords up to an untruncated length of 32 significant bytes.

GSEC [add | modify], IBConsole, and the IB Services API support the SHA-1 password hash algorithm. Any of these tools can be used to maintain the passwords of server-wide user accounts. If an existing user account has had its password changed then that user must log in to the server using the new IB client library.

Caution: There will be backward compatibility problems if the converted admin.ib database is backed up and restored by an older IB engine after the password hashes have been converted to SHA-1. Older IB engines will not understand the different password hashes and will cause unrecoverable login errors.

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.

InterBase XE now provides support for the EXECUTE STATEMENT functionality.

        User Interface/Usability

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.

No Rows or Data Returned

EXECUTE STATEMENT <statement>

<statement>         ::= a SQL statement returning no rows of data

Example:

CREATE PROCEDURE EXEC_STMT_NO_RET (proc_name varchar(20))

AS
DECLARE VARIABLE EMPNO INT;

DECLARE VARIABLE EXECSTMT;

BEGIN

   SELECT MAX(EMP_NO) from EMPLOYEE into EMPNO;

   EXECSTMT = 'EXECUTE PROCEDURE' || proc_name || '( ' || cast (EMPNO as varchar(10)) || ')';

   EXECUTE STATEMENT EXECSTMT;

END

One row of data returned

EXECUTE STATEMENT <select-statement> INTO :<var>[, :<var>..]

<select-statement>::=         SQL statement returning one or no rows of data

<var>      ::=         valid procedure variable, the ":" is optional.

Example:

CREATE PROCEDURE EXEC_STMT_SINGLETON (TABLE_NAME VARCHAR(50))

AS

DECLARE VARIABLE MAXEMPNO

BEGIN

EXECUTE STATEMENT 'SELECT MAX(EMP_NO) FROM' || TABLE_NAME INTO :MAXEMPNO;

SUSPEND

END

Any number of data rows returned

FOR EXECUTE STATEMENT <select-statement> INTO :<var> [, :<var> ..]

DO <compound-statement>

<select-statement>::=         SQL statement returning one or no rows of data

<var>            ::= valid procedure variable, the ":" is optional.

Example:

CREATE PROCEDURE EXEC_STMT_ANY (TABLE_NAME VARCHAR(50), INT_FIELD INTEGER)

RETURNS

(INT_RETVAR INTEGER)

AS
DECLARE VARIABLE IFIELD INTEGER

BEGIN

FOR EXECUTE STATEMENT

'SELECT' || INT_FIELD || 'FROM' || TABLE_NAME INTO :IFIELD

   DO

      IF (IFIELD = 0) THEN

         INT_RETVAR=0;

      ELSE

         INT_RETVAR = INT_RETVAR+IFIELD;

   SUSPEND;

END

New Error Messages Added
The following table displays the new error messages added:

SQL Code	Error Number	Error Message
-204	335544850	EXECUTE STATEMENT could not prepare statement : <string>
-204	335544851	SQL statement invalid as it returns no records. SQL : <string>
-204	335544852	Parameter mis-match for the statement : <string>
-204	335544853	Could not execute statement : <string>
-204	335544854	EXECUTE STATEMENT fetch error
-204	335544855	EXECUTE STATEMENT in this form must return single row, not multiple rows.
-204	335544857	Sql statement not allowed in EXECUTE STATEMENT : <string>

Requirements/Constraints
There are constraints and peculiarities with using EXECUTE STATEMENTS:

• The Statement is "prepared" every time it is executed which will affect the performance of the Stored Procedure.
• No checks are done on the statement when the procedure is created; dependency checks are not done when the procedure is created, also the checks for existence of tables or column names referred to in the execute statement are not performed. All these checks will be done at execute time and will result in errors if an error condition occurs.
• The feature can be used to perform DDL operations.
• All statements are executed based on the privileges of the user executing the Stored Procedure.
• SQL statements, "COMMIT", "COMMIT RETAIN", "ROLLBACK", "ROLLBACK RETAIN" and “CREATE DATABASE” are not supported with EXECUTE STATEMENT. These statements return the error code isc_exec_stmt_disallow.

Migration Issues
This feature is only available in InterBase XE and is not backward compatible.

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.

InterBase databases periodically need to be swept. Otherwise the main memory allocated for each transaction's bitmap increases to the point where performance becomes unacceptable. The longer sweep takes to complete, the more main memory requirements increase for starting new transactions.

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. In cases where large databases have large archival or infrequently modified tables, a database sweep will have minimal impact on the performance of running transactional operations.

User Interface/Usability

There is no new user interface or action required by the user to enable this functionality. Manual sweep initiated by the GFIX command line tool, IBConsole, or programmatically, as well as automatic sweep configuration on a database, use the fast sweep mechanism.

Requirements and Constraints

• Only ODS 15 and later databases can perform fast database sweeps.
• The effectiveness of a fast sweep is directly proportional to the fraction of database data pages that have been modified since the last sweep. If every data page has been changed, fast sweep is no faster than the former methodology. If very few pages are changed, fast sweep is nearly instantaneous. If half the pages were updated, fast sweep is then half the former sweep time.

Migration Issues

A database needs to be created or backed up and then restored to ODS15.

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.

In InterBase XE, ODS 15 databases introduce table-specific blocking factors that optimize how many rows can be stored on a data page and minimizes the row number assigned to a row. In addition, the engine minimizes the size of a number of run-time data structures. This is especially important as tables storing a very large number of rows and accessed by a large number of database connections can cause excessive memory consumption.

User Benefit

Databases with tables containing a large number of rows or is expected to grow to a large number of rows benefit from table-specific blocking factors. It allows those tables to store more rows in the same record number space, while using less memory for run-time retrieval data structures.

User Interface/Usability

There is no user interface or any action required by the user to enable this functionality. The table-specific blocking factors are set automatically after a database restore.

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.
  
  If a table does not have a table- specific blocking factor, this system column will query as NULL. Each time a database restore is performed, these blocking factors are retuned for the actual row data restored. Therefore, it is possible that these values will change over time as the database is modified and is backed up and restored.

Requirements and Constraints

• Only ODS 15 and later databases have table-specific blocking factors.
• Not all tables are capable of having a table-specific blocking factor.
• If a table has Blob columns and no indexes defined, then that table uses the database-wide blocking factor as its Blob blocking factor.
• System tables, views, external tables, and temporary tables do not use table-specific blocking factors.
• A table-specific blocking factor cannot be modified in-place once it has been set by database restore.

Migration Issues

If an ODS 15 database has been created and loaded with data, taking a backup and restoring will set the table-specific blocking factors.

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.

Because InterBase XE supports UTF8 and multiple other multi-byte character sets, the limit has been increased. For example, a single-column key using 4-byte UTF8 character would calculate to 1020/4 = 254 UTF8 characters with a 4KB page size.

ODS 15 databases automatically allow index definitions where the underlying key size is now a factor of the database page size.

• An index key can now be up to 4 bytes less than 1/4th the page size.
• By default, InterBase databases are created with a 4KB page size. This can be overridden up to 16KB page size by the database developer.
• The 4KB page size database would allow indexes that can accommodate 1020 bytes per key.
• A 16KB page size can accommodate 4092 bytes per key and so on.

Requirements and Constraints

Databases created with engines enabled with this functionality cannot be moved back to older versions of InterBase.

Also a database restore to a smaller page size will fail if indexes with a large key size cannot fit within limit specified above.

No user interface or actions are required by the user to enable this functionality. Each time a database restore is performed, the indices are recreated.

Migration Issues

Only ODS 15 and later databases have support for larger index keys. If you want to use this facility, restore your database to ODS 15. Other indices that use a smaller size than 252 bytes continue to have the same on-disk storage without any penalty.

Run the executable ib_install.exe (for 32-bit) and ib64_install.exe (for 64-bit), and then choose one of the following:

         Server and Client
After you choose an install location; this will replace the binaries in the existing InterBase installation. Make sure to stop the InterBase Server before installing.

         Client only
This will install all of InterBase command line tools as well as the IBConsole.exe and the InterBase JDBC Driver.

         Extract Files only
This will extract the files in a single directory to be installed at a later time by the user.