This document contains several sections:

• Important Caché News, Alerts, and Advisories
• General Improvements
• Online Documentation
• Description of a Change Report
• A list of changes considered critical for this release
• A summary of new / improved features and functions
• A summary of changes to the documentation for this release

From time to time, InterSystems publishes items of immediate importance to users of our software. These include alerts, mission critical issues, important updates, fixes, and releases of Caché.

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.

When appropriate, InterSystems adds general improvements to the features and functions of Caché beyond those required by critical fixes. Such improvements are contained in this version.

As a convenience to our users, InterSystems provides online access to documentation for recent versions of Caché at the InterSystems Website.

From the home page choose the "Caché" tab, and on the "Downloads" menu, select "Documentation and Help Updates" or follow this link.

To help you assess the impact of these changes on your applications, each change description contains a more detailed explanation of the modification.

All changes include a table giving pertinent information on the issue's likelihood, impact of the change, and whether this has already been used successfully in production by other customers. In order to make the information easy to assimilate visually, the tabular information has been simplified to a keyword or two and a value. The full explanation of the keyword meanings are:

• Likelihood - The probability that a user on the affected platform will encounter this issue.

• Risks - An assessment of how likely this change is to introduce additional issues into the application environment.

• Ad Hoc - Whether this change has previously been deployed in an ad hoc release and successfully used by customers in production.

• Enhancement - Whether this change provides new features or capabilities.

This change ensures uniqueness in server names and address fields when a new server is added.

This change corrects an issue with the Control Panel. Prior to the modification, every time a Local Database was expanded a new entry was added to the lock table. These lock entries were removed only when the Control Panel was closed. With the correction, the lock is released when the expansion is finished.

If you have a form in a Web page such as:

<form name=form1 method=post action='textarea.csp'>
<textarea name=txt rows=15 cols=100 value="">
</textarea>
<br><input type=submit name="btn" value="Submit">
</form>

And the text area contained more than 32k of data then the CSP server was crashing. Now it creates a stream to hold all the data and when you access %request.Data("txt",1) you will get the stream oref. This means that for any fields that could be larger than 32KB, you should code something like:

Set value=%request.Data("fieldname",1)
If $isobject(value) {
  ; Treat this as a stream
} Else {
  ; Treat this as a regular string
}

Before this change, the passing of JavaScript boolean values as #server or #call arguments was inconsistent. A boolean value passed by #call or #server is "true" or "false"; the Java applet based #server in IE passes these values as -1 or 0; and the Java applet based #server in Mozilla passes these values as "true" or "false". No upward compatible solution is consistent, so we are implementing the most Caché like solution of passing true or false as 1 or 0.

The implementation of this change is designed to make it fairly easy for a customer to back out the change if desired. The adjustment of the JavaScript boolean value is done in the JavaScript function cspMakeBoolean in <CacheDirectory>/csp/broker/cspbroker.js. Comments are included in this function explaining how to restore functioning to the previously inconsistent model.

The programmer will need to adjust the application code if passing boolean value arguments by #call or #server. In this case, scan the code for tests for equality to "true", "false" or -1 and change the code to expect 1 or 0 as the Caché value of the boolean.

This change resolves an issue in which the Gateway's Systems Management suite would not operate for cases where the path to the IIS root contained a period. For example:

C:\Inetpub\www.com\Website

Calls to the systems management suite resulted in an 'Invalid Request' error being returned to the browser because the 'www.com' component that was confusing the Gateway's logic for identifying requests for Systems Management forms.

In general, having periods in file paths (that is, in directory names) to Web resources can cause ambiguities and confusion. This is particularly true for cases where the entities in question are virtual (as is the case with CSP-based resources).

If StoreAttachToFile property of %Net.POP3 is true, then attachments are saved to the directory specified in AttachDir. An attachment is indicated by the "Content-Disposition=attachment" header. Previously the file would only be saved if the filename attribute was specified in the content-disposition header.

Now %Net.POP3 will save all attachments, generating the file's name as follows:

1. If filename specified on Content-Disposition filename attribute, then use that.
2. If filename specified on Content-Type name attribute, the use that.
3. Otherwise create a temporary name of the form ATTxxxxxx.dat

Prior to this change, when you run Tune Table through SQL Manager, if the calculated Extentsize is zero, the selectivity functions will still be called and updated. After this change, if the calculated Extentsize is zero (meaning there is no data), then the selectivity functions will not be called resulting in no changes saved to the table. A message will display:

Table extentsize = 0. No changes will be made.

With this change, Caché rebuilds its routine index global only when it is needed. Prior to the modification, the index was often rebuilt unnecessarily which resulted in a performance slowdown.

This change avoids installation conflicts with Caché running on a different node. It applies to UNIX and OpenVMS installation procedures.

When a $CASE function was used as the argument for a GOTO command, there could be an access violation when compiling the routine or an unexpected error when executing it. This change removes that possibility.

A Caché process could get an access violation when compiling a $ZSORT() function which had an invalid second parameter. This correction eliminates that situation.

This corrects a typographic error in a label that could cause ECP recovery to fail.

Caché on OpenVMS logged a SYSLOG entry for every LAT session start and stop. This change modifies Caché not to log an entry on session enter and exit.

If %OpenId is called with an ID value that contains multiple components, and one of those components is null, then an error will be returned indicating that the ID value is invalid.

For example, Class A is persistent and has two properties, P1 and P2. There is an idkey index on P1 and P2. ##class(A).%OpenId("abc||") will not succeed and the error message will indicate that one of the ID component values is null.

Previously, a <SUBSCRIPT> error would have been reported.

Unique constraints that originate in a class are not properly enforced when inherited by a subclass because the origination of the constraint is not projected to SQL.

Caché now qualifies any unqualified class names projected to SQL as constraint origination classes.

IDKEYs (aka ROWIDs) are either simple values or multiple values delimited by "||". When a value is a reference to another class and that reference also contains "||" characters (the referenced class has an IDKEY based on multiple properties), then Caché must keep track of the number of "||" characters expected to be in each component value of the IDKEY. It uses that information to extract the individual IDKEY component values using $PIECE.

When a class is a child, and the IDKEY of the parent is based on multiple properties, and one or more of those properties is a reference to another persistent class whose IDKEY is also based on multiple properties, then the storage compiler would generate incorrect code to save the data. This is because it was making an assumption that all parent properties (identity properties) did not contain component values.

This has been fixed.

SQL was not properly enforcing an inherited uniqueness constraint. For example, suppose Class A is a persistent class with a property, P1, with an index, I1, on P1 which is defined to be unique.

Then, further assume Class B extends Class A.

Prior to this change inserting a row into Class A will fail if the value provided for P1 already exists in the extent of Class A. However, an SQL insert into Class B will incorrectly succeed if the value of P1 exists for a row in Class A.

This has been fixed.

An error has been fixed where a unique constraint was inherited by a subclass and an INSERT was allowed into the subclass's table such that the unique constraint as defined in the base class was violated.

A problem has been corrected in the SQL table compiler where an index map might not produce the correct filing code if an overriden full row reference was used for the map.

Also, a problem has been corrected in the SQL table compiler where code to determine if a value exists for a field in any row of the table might not produce the correct code if an index was defined with a structure like:

^[$Piece(LVar({F1}),",")]Glo("a",{F1},{ID})

Both of these problems resulted in incorrect syntax generated for the table filing routines.

An error has been fixed where an INSERT/SELECT statement would crash with an <INVALID OREF> error if the table being inserted into had a stream field that was not specified in the insert column list.

A problem has been corrected in the Caché Macro Preprocessor where a <UNDEFINED> error might occur in the preprocessor's error trapping, masking the real error it was attempting to report.

A error was corrected where a view with a sub-query in the view query's WHERE clause was incorrectly treated as a potentially updateable view causing an <UNDEFINED> error during compilation. This change makes Caché SQL views with any subqueries in the view's query not updateable.

Prior to this change, a table might fail to properly compile code responsible for filing the data if %CacheSQLStorage was used, and a field in the map data was the IDKEY field of a parent/grandparent table, and the IDKEY of that table was based on the single field.

This has been corrected.

This change fixes the problem with DSNConfig, and updates the parameters to take the following keywords for Caché 5.0:

1. User or UserName or UID
2. PWD or Password
3. Host or Server
4. Port
5. Description
6. Namespace or Database
7. Unicode SQLTypes
8. Static Cursors
9. Query Timeout

These keywords are case insensitive.

If a keyword is not defined, appropriate values are assigned with the exception of UID and PWD.

To pass this into the ConfigDSN API, you must format a string with "\0" separators between each keyword=value pair. The entire entry must be followed by a double "\0". For more details on the use of ConfigDSN, see the Microsoft online documentation.

The following is an example of such a string. It has been broken up on multiple lines for readability.

DSN=Testing\0
    Namespace=User\0
    Host=myhost\0
    Port=1976\0
    Description=My own private server\0
    UID=someone;Pwd=passwd\0\0

Previous speed improvements for queries with GROUP BY or DISTINCT have been extended to apply in more cases, and also to work correctly in a few cases in which problems occured, such as where an indexed property containing NULL values had caused a <SUBSCRIPT> error or an infinite loop when running certain queries.

When TOP and ORDER BY are specified, this change promotes the choice of access paths that do not build temp-files. This produces the first few rows faster (for example, by using an index that matches the ORDER BY), rather than choosing the access path that is judged to be the fastest in returning ALL the rows that satisfy the query.

A problem has been corrected where a statement like:

SELECT OPTION LOCK_TIMEOUT = 30

would not Prepare when using a Dynamic Query.

A condition has been fixed where:

INSERT INTO MyTable1,... (MyStreamField1)
    SELECT MyStreamField2,... FROM MyTable2

would crash with an SQLCODE=-400 error for cases like:

INSERT INTO MyTable1,... (MyStreamField1)
    SELECT 'some literal',... FROM MyTable2

or

INSERT INTO MyTable1,... (MyStreamField1)
    SELECT NULL,... FROM MyTable2

A problem has been corrected in the table compiler when compiling large tables where an <UNDEFINED> error would occur in some cases when splitting the generated table filing code into multiple routines.

An error has been fixed where an SQL UPDATE statement might not save the data correctly if the class used %CacheStorage, and had about 185 fields in the table, when all were stored on the same node in the data (master) map.

This changes SQL Manager's QueryPlan to use "/csp/docbook/" instead of "/apps/documatic/" in the URL. The former will not consume an extra license and will clean up CSP session correctly.

This change corrects a problem with SELECTIVITY where a property may be indicated incorrectly when you switch tables under certain conditions. Now, after the table fields are loaded, the selectivity box and label will be set to null. These two fields will be filled when you click on any row.

This fixes a possible access violation when attempting to run a routine that received a <ROUTINE TOO BIG TO SAVE> error.

This change addresses an issue on Caché for OpenVMS systems configured with the option SwitchOSdir=1 set, where the OS directory of a user login process didn't get passed on to a jobbed job.

Addressed an issue on Caché systems configured with the option SwitchOSdir=1 set, where the OS directory of a user login process didn't get passed on to a jobbed job.

In some character sets used by 8-bit locales, some characters are left undefined (such as 0x98 in CP1251). In the corresponding UnicodeLittle and UnicodeBig translations, these undefined characters used to map to '?'. This feature made it impossible to perform round-trip binary translations, such as CP1251->UnicodeLittle->CP1251, without losing data.

Since UnicodeLittle is used for communication between clients and servers in several situations (such as shadowing), in which binary data may be involved, the UnicodeLittle and UnicodeBig translations have been changed so that undefined characters now map to themselves in both directions. This has no effect on text data and allows binary data to do round trips without any loss.

The affected character sets are: CP874, CP1250, CP1251, CP1252, CP1253, CP1255, LatinG, LatinH.

GCOMPACT did not check to see whether switch 10 or 13 was set except between globals. The result is that if GCOMPACT is running, a BACKUP or other activity which has a timed wait for the system to quiesce could fail.

GCOMPACT has been updated to check for switches while it is processing a global so that it will pause more quickly when a switch is set.

Internal retry loops were added to fsync() calls for UNIX platforms to wait for a succesful completion if there is an error. fsync() is used on UNIX during database expansion, writing the journal file and when writing database blocks to the WIJ and cache.dat files to flush the UNIX buffer pool out to disk so the writes are known to be persistent.

Operating system calls to sync data to disk during file expansion for 8-KB databases on UNIX systems have been enhanced to avoid possible problems on certain types of devices. Prior to this channge, problems in this area would show up as a serious disk write error occurring in the write daemon following an expansion which appeared to succeed even though there really wasn't enough disk space available for the newly allocated blocks.

This prevents accidentally setting the New Global Pointer Block to 0.

The ability to prevent simultaneous startups of Caché configurations on different network nodes has been added to Caché. This feature applies to configurations that share the same physical directory, but have been installed on different machines, such as members of a cluster.

The current change blocks starting or stopping Caché if the directory is already in use on a different node instead of the local node. It does not provide protection against mounting a database or accessing a file that is in use on a filesystem shared among machines. That is the responsibility of the user/application.

The ccontrol "list" and "all" commands have been modified to identify configurations in use by a different network node.

This startup conflict avoidance mechanism involves recording the system (or node) name in the cache.ids file during startup. Thus, all machines which can share the physical file system containing the Caché configuration should have unique names. Under UNIX, this is the node name shown by the uname -n command, not the Internet name from the hostname command, which might be somewhat different.

This change corrects an error in COM port handling that caused memory leaks with JOB servers as well as an previous problem with JOB servers.

Prior to this correction, running Caché backup on an instance of Caché with more than 256 databases mounted could cause the label block and incremental bitmap blocks of one database to overwrite blocks of another database. This problem affects Caché 5.0 on all platforms except for OpenVMS and Tru64 UNIX.

A confusing and spurious error message that was reported to the Windows event log if Caché required a long time (>10 minutes) to start (due to a long running ^ZSTU routine) has been removed. The message read:

Cache service process creation failed, child did not return;
Cache configuration CACHE error: 997.
Cache Control Service Startup failed; Cache configuration CACHE: .

The message is spurious because Caché did indeed start.

This fixes a situation where a control process crash prevented cforce from completing on Windows systems due to events not being available to Caché processes. Now cforce halts processes even if all events are not available.

This corrects a problem where cforce fails to terminate by force jobs that cannot be terminated cleanly during shutdown, possibly leaving jobs behind after cstop or cforce.

ECP daemons were running at low priority (5 on Windows and 2 on UNIX). This change now has the daemon run at normal user priority (7 on Windows, 0 on UNIX).

This corrects an error where the wrong result was be returned by $DATA(^global,variable). It occurred when a global was stored in a new format (that is, 8-KB block) database and the two-argument form of $DATA was being used on a top-level global node which was undefined but which had descendants.

It now returns the proper vaue, 10. Previously, it had returned 0.

When the DCP server has some locks from DCP clients, and is shut down and restarted, the locks on DCP clients may get into 'Lost' state because the upload of lock information from client to server may fail.

This has been fixed.

This change fixes a lock memory corruption problem when an ECP client locks the server node and the ECP server node has SWITCH 10 or 13 turned on (such as on Caché backup). Previously, it only failed when a child node already been locked and it tried to lock the parent node.

This change corrects a problem with the non-interactive API for restoring backups, $$EXTSELCT^DBREST. Under some circumstances, an <UNDEFINED> error would be reported when attempting to skip over a database entry not flagged for restore in the directory list (that is, excluded from restore in a multiple database backup archive).

This change addresses an issue where a shadow configured to start at startup could cause <UNDEFINED> error when it began.

This fixes a problem using %RI. Priot to the change, it would allow you to unintentionally overwrite object-code-only routines. This change refuses to load a routine if you say YES to Compile? and NO to Replace? and the object code version of the routine still exists.

This fixes a problem where a wrong routine list may be produced by routine utilities because the ^mtemp indices become inconsistent.

This change improves and extends the exception handling and automatic recovery mechanisms in the core Event Broker (EB) service. The core Event Broker service is the dedicated TCP service that usually listens on port 7001 and is used in the non-HTTP modes of EB operation (for example, mode 0).

This correction was motovated by a problem in which the EB service closed down unexpectedly in a production system.

In addition to critical fixes, this version of Caché contains improvements to specific areas of the product. They area summarized by area as follows:

This version of Caché adds support for the following locales: Thai, Arabic.

Numerous changes and enhancements have been made to Caché SQL and Objects. Among them are:

• Java
  
  • A new class flag has been added to map Caché datatypes into primitive Java datatypes (int, double, boolean, and so on) rather than the corresponding Java wrapper datatypes (java.lang.Integer, java.lang.Double, java.lang.Boolean, and so on).
  • A flag has been added to the class definition that projects Caché collections as instances of the Java Collections framework. For example, arrays are projected as instances of java.Util.Map and lists as java.Util.List. This eliminates deprecated warnings caused by using obsolete classes such as com.intersys.classes.ListOfDataTypes.
  • The methods addToBatchInsert and executeBatchInsert are now generated for projections of all persistent classes. The speed of batch and bulk operations has been improved, and the sensitivity to the size of the batch for an operation has been removed.
  • Caché methods that return instances of %ResultSet can now be projected as returning instances of java.sql.ResultSet. This makes the use of Web services by the Java Binding more efficient.
  • A method, closeAllObjects, has been added to the Database interface. This method closes all opened objects withoput destroying the database itself.
  • JDBC has been changed to support the return of multiple ResultSets from a method call.
  
  
• %server
  
  • The server has been thoroughly revised and improved.
  • The device buffer size for %server has been increased to 64KB.
  • Java now uses %server instead of %qserver.
  • Error reporting has been improved.
  • The use of static cursors is now supported.

• Other
  
  • ^CacheTemp is no longer used to hold the data for cached queries that do UPDATEs.
  • A new column, ORIGINATING_PROPERTY, has been added to the %Library.SQLCatalog.SQLFields() query. This column contains the name of the Caché class property which corresponds with the SQL Field.
  • Caché now fully implements JDBC setMaxRows/getMaxRows and ODBC SQLSetStmtOption/ SQLGetStmtOption where the option is SQL_MAX_ROWS. This option limits the number of rows in a result set. Prior to this, pruning of the ResultSet would be done on the client side. NBow this is done on the server side to improve efficiency and memory utilization on the client.

This version of Caché nows installs and executes natively on Macintosh OS X 10.3. The installation kit is a standard ".dmg" distribution produced by PackageMaker.

Many changes have been installed in this version of Caché to better handle the condition where the database, or the disk volume containing the database, becomes full. Among the more important of these are:

• On UNIX systems, if the filesystem which hosts the CACHETEMP database becomes full, it would be possible for jobs to get <DATABASE> or <DISKHARD> errors accessing CACHETEMP. Now jobs will get <FILEFULL> errors if CACHETEMP becomes full until space is freed up on the disk volume or within the database. If space is created within the database by killing unused globals (for example, from jobs which no longer exist), the system will not allow block allocation from CACHETEMP until all of the blocks which it has failed to write are either succesfully written (because space on the disk was made available) or the blocks involved have been killed. The console log contains a list of blocks which the system is trying to write to disk.
  
  
• Following a database expansion Caché now checks the free space remaining on a disk (or in a database, if a maximum size has been specified) and will generate a cconsole.log warning if space is getting low. If there are multiple databases on a single disk, each database will generate its own set of warnings.
  
  
• An enhancement was implemented to alleviate a performance problem which arises when database blocks scheduled to be written drop down to the bottom of the buffer management queue. The improvement is that dirty buffers that drift to the bottom of the LRU queue are removed from that queue and placed in the regular write daemon queue so that they are written on the next write daemon pass.

Journal restore has been made more robust in this version. Among the more noteworthy channges are these:

• The journal restore now selects the proper file to start with in the case where there exists a file whose name collates after that of the last journal file AND doesn't end with YYYYMMDD.NNN (excluding the trailing version # on OpenVMS).

  In prior versions, it would choose the latter (that is, wrong) name as the name of the journal file.
  
  

• In rare circumstances, a shadow in fast mode (also called block mode) may fail to apply updates from databases that are newly mounted on the main server for the first time since Caché started. The problem is present on all platforms in all prior Caché versions. This is now fixed.
  
  
• This version addresses a problem where purging of shadow journal files would fail if the shadow and the server run on “different” operating systems. (For purposes of this fix, all flavors of Windows are considered the same operating system, and all flavors of UNIX, including Linux, are considered the same.
  
  
• On prior versions, in the unusual case where the journal daemon failed to open a journal file, it would quit. The only recourse was to restart Caché since the daemon does not restart. This has been changed to treat failure to open a journal file as an I/O error so the journal daemon remains active while the problem is addressed.
  
  
• If the last remaining node of a cluster crashes, restarting the cluster (that is, the first node of the cluster) involves cluster journal recovery, which includes rolling back any transactions that were open (uncommitted) at the time of crash.

  This version addresses a problem where the rollbacks in this case were not visible to cluster journal restore or cluster shadowing, and could lead to incorrect result on the restored or shadow databases.
  
  

• At the end of journal restore, this version of Caché has more informative operator messages during journal recovery. It now indicates when all records have been read from the journal, and then display progress messages as the application of journal records to the database proceeds, until completion.

  Previously, it misleadingly indicated that the journal processing was complete when all records had been read, but before they had all been applied.

This version of Caché includes a number of improvements in shadowing performance:

• Performance of shadow dejournaling, especially that of fast-mode shadow, has been improved by moving the dejournaling code to the Caché kernel from Caché ObjectScript routines.

  In addition, Caché now employs separate jobs to read the journal and apply database updates. For example, for a fast-mode shadow, there is a job fetching journal files from data server (the "source"), a job ("journal reader") reading journal files copied over, one or more jobs ("database updaters") applying journal updates to databases and, optionally, one or more jobs prefetching globals from databases.

  Warning: Since the journal reader and database updaters communicate via shared memory allocated from the generic memory heap, it is important that one configures the generic heap as large as possible for the optimal performance of shadow dejournaling. The minimum requirement is 4 pages for shadowing. Shadowing may fail to start if there is insufficient space in the general memory heap.

  Depending on the data sample and platform, the performance of dejournaling (including rollback) is on par with the previous performance in the worst case scenario and can be several times as fast in the best case scenario. There are no changes required in existing Caché applications.
  
  

• Shadowing has been changed so that it is interruptable. In prior versions, shadow journaling a large file would cause long delays in reponding to requests because it would not process the request until the file had been fully processed.
  
  
• In prior versions, the global node used to store the cluster shadow checkpoint info could grow indefinitely and might eventually consume a substantial amount of database space. The change in this version removes nodes that are no longer needed during processing.
  
  

Support has been added to Caché for the BigInt datatype, that is, integers in the range -9223372036854775808 to 9223372036854775807 inclusive. This support includes:

• adding a BigInt datatype class to the %Library package
• proper handling of data in this format by SQL, ODBC and JDBC
• adding support for this type in the various %XML classes
• adding code to handle BigInt variables in Caché objects

The content of the Caché documentation evolves from release to release in response to editorial improvements, updates to existing material, and addition of new information. The following is a summary of the most noteworthy changes to the Caché documentation since the previous release:

• Caché I/O Device Guide
  
  • Clarified the explanations of TCP devicename and port number.
  • Added new information regarding how OpenVMS handles files opened in modes "H", "F", and "B".
  
  
  
• ObjectScript Reference Manual
  
  • Added a table of abbreviations to the beginning of the book to collect all of them in one place.
  • Added documentation of the $LISTSAME function which compares two lists for equality.
  • Added documentation describing %ZLANG and its use in extending ObjectScript's "builtin" functions and special variables.
  • Expanded the description of ZSAVE to include cautionary material regarding the potential for name conflicts in networked systems because of concurrency.
  • Added an explanation of the possible performance effects of using $DATA to access globals on non-local systems in a networked environment.
  • Updated the documentation on the ZBOOLEAN function to better explain its use with mixed number and string arguments and the forced conversions that take place; added its abbreviation, $ZB.
  • Clarified the interactions (and dangers) of using KILL commands to delete Caché objects rather than removing them using object methods.
  • Added symbols used by embedded Java and HTML to the table of symbols.
  
  
  
• SQL Reference Manual
  
  • Clarified the handling of NULL values in conjunction with the following: CREATE TABLE, ORDER BY, SELECT DISTINCT, and arthmetic computation in formulas.
  • Added references to equivalent methods calls in the $SYSTEM.SQL class for: ABS, ALPHAUP, CEILING, DAYNAME, DAYOFMONTH DAYOFWEEK, DAYOFYEAR, FLOOR, HOUR, MINUTE, MONTH, QUARTER, SECOND SQLSTRING, SQLUPPER, STRING, TOCHAR, TODATE, WEEK, and YEAR; added information on how to invoke the methods generally.
  • Added information on the default behavior and specifications for ALTER TABLE, CREATE USER, and %EXTERNAL (datatype).
  • Updated the information on COMMIT/ROLLBACK/START TRANSACTION; transaction size limitations; lock escalation on INSERT, DELETE and UPDATE; and how uncommitted data is handled.
  • Added information on how fractional precision is handled in date and time functions.
  • Added information on the use of “{...}”, “::” in trigger code, and integer division to the Symbols section; updated the related material in CREATE TRIGGER and elsewehere.
  
  
  
• Using Caché Multi-Dimensional Storage
  • Updated and edited the material for improved clarity.

These are in addition to minor enhancements in examples, as well as corrections and improvements to grammar and spelling.