1. Title to and ownership of the software and documentation shall remain with the Contractor.
2. Use of the software and documentation shall be limited to the facility for which it is acquired.
3. The Government shall not provide or otherwise make available the software or documentation, or any portion thereof, in any form, to any third party without the prior written approval of the Contractor. Third parties do not include prime contractors, subcontractors and agents of the Government who have the Government's permission to use the licensed software and documentation at the facility, and who have agreed to use the licensed software and documentation only in accordance with these restrictions. This provision does not limit the right of the Government to use software, documentation, or information therein, which the Government has or may obtain without restrictions.
4. The Government shall have the right to use the computer software and documentation with the computer for which it is acquired at any other facility to which that computer may be transferred; to use the computer software and documentation with a backup computer when the primary computer is inoperative; to copy computer programs for safekeeping (archives) or backup purposes; and to modify the software and documentation or combine it with other software. Provided that the unmodified portions shall remain subject to these restrictions.

The most current list can be obtained from the InterSystems Website.

Users should check this list periodically to obtain the latest information on issues that may have an effect on the operation of their site.

• Phone:  +1  617  621-0700
• Fax:  +1  617  734-9391
• Email:  support@intersystems.com

When application code errs with a transaction level > 0, Caché does a TROLLBACK in the error trap. Otherwise, the transaction level will never go down to 0 and this will cause inconsistencies in processing afterwards.

This change added TROLLBACK for the user callback in Business Services, Processes and Operations.

This change also fixes three other places where similar cache table subscripts are used.

• Large Object detection was not recognizing certain SQL Server types properly.
• JDBC calls to the removeLOB() cleanup function were missing an argument and therefore failing.
• The Large Object byte position appendage to the field ID in GetData/GetDataW() was not being tested properly, causing a failure to fetch all field data.

This change also adds Java type definitions to EnsSQLTypes.inc and adds new methods each to EnsLib.SQL.GatewayConnection and EnsLib.SQL.Snapshot:

• GetColumnSQLType - Returns the SQLtype integer of column 'pColumn' in the result set.
• GetColumnIsLOB - Returns whether column 'pColumn' is a LOB (Stream) column.
• GetColumnIsBinary - Returns whether column 'pColumn' contains binary data.

This change forces the client to assume that after a roundtrip to the server the client cache must be valid, even if the server didn't send any updates. As a result, the client should not send extra messages to the server.

If there are many rows inserted or updated in a single transaction and many foreign keys on the table, this could hold many locks in the lock table.

With this change, Caché will no longer hold the lock for the duration of the transaction, but will release the lock after the row has been inserted or updated. By this time the system has ensured referential integrity and the row in the referenced table cannot be updated or deleted during the course of this transaction because the referential action on the foreign key constraint will prevent the update or delete on the referenced table from occurring.

The symptom is that the cluster manager would become unresponsive and the Caché cluster resource will not work. This problem has been seen on 64-bit Windows, but may also occur on 32-bit Windows clusters.

The problem is believed to be present in all supported Caché releases.

Now the installation will complete, allowing administrators to fix the CPF file, and restart to be upgraded to the new version.