By: Sriram Balasubramanian
Abstract: InterBase 2007 Service Pack readme
This file contains important information that may not appear in online Help. Read this file in its entirety. InterBase 2007 Service Pack 3 (version 220.127.116.113) update should be applied to InterBase 2007 Service Pack 2 installations. It contains all the fixes done since InterBase 2007 Service Pack 2 (version 18.104.22.1687). You can download the updates from http://cc.codegear.com/reg/interbase
Run the executable IB2007_SP3.exe, 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 client tool executables and the type 4 InterBase JDBC Driver. Please note that the updated interclient.jar will be installed in the <interbase>\SDK\lib folder as compared to the SP2 location of <interbase>\lib; make sure you delete the old version and point your JDBC settings to the new jar file.
� Extract Files only
This will extract the hotfix files in a single directory to be installed at a later time by the user.
Extract the tar file IB2007_SP3_Linux.tar. After extracting the files, replace the files in the appropriate directory.
Extract the tar file IB2007_SP3_Solaris.tar. After extracting the files, replace the files in the appropriate directory.
The following are resolved defects in this InterBase 2007 service pack
Internal Defect #
External Defect # (QC)
Service Pack 3: 17-Nov-2008, version 22.214.171.1243
gfix -validate -full exhibits index corruption messages on table RDB$DEPENDENCIES
Nested loops in triggers crashes the server
Using table alias in UPDATE statement gives error
Incorrect results from left outer join query
CodeGear InterBase Multiple Vulnerabilities
Query with explicit and implicit joins results in “no current record for fetch operation” error
Running a select statement with specific OR conditions causes the InterBase server to crash
Validating a freshly restored database reports many errors in index RDB$DEPENDENCIES
Server crash on select from table with date indexes
Distinct in nested queries can return incorrect results
concurrent delete and select (and probably insert) cause database to be corrupted. "internal gds software consistency check (exceeded index level)" error in interbase.log
Join with Stored Procedure returns incorrect results
restore using gbak with buffers set high and -o (one at a time) causes server to crash
Inner Join between two views which both have left joins results in error “no current record for fetch operation”
If journal files are lost, connecting to the database may fail.
Fix notes: A new GFIX switch (-disable wal) is provided to disassociate a database from its journal files. No cleanup of the journal files or journal archive files is attempted and it is the case that committed data may have been lost. This could occur because the lost or inaccessible journals may have committed data that was never applied to the database files proper. However, it becomes possible to attach the database to access existing data contained therein.
Interbase 7.5 and 2007 Numeric Type have Bug
Server crash with big SORTMEM_BUFFER_SIZE on restore
Running GBAK as a service incurs high CPU usage in the server
JDBC: DataBaseMetadata.getTables() does not work with delimited tables/columns
JDBC: DataBaseMetadata.getTables() wrong ordering of resultset
JDBC driver: Calling PreparedStatement.addBatch() more than once results in error when calling PreparedStatement.executeBatch()
Following are files in this update:
� ibserver.exe (bin directory)
� IBConsole.exe (bin directory)
� gfix.exe (bin directory)
� interclient.jar (SDK\lib directory)
� ibserver (bin directory)
� gfix (bin directory)
� interclient.jar (lib directory)
Copyright � 2008 Embarcadero Technologies Inc. All CodeGear brand and product names are trademarks or registered trademarks of Embarcadero Technologies in the United States and other countries. All other marks are the property of their respective owners.
Server Response from: ETNASC02