Operational Differences between MultiValue and Caché
Different operating and applications systems permit different characters to be used in file names. While they all agree on uppercase alphabetic characters and digits, they differ on the rest. The following are the rules Caché MultiValue uses for converting file names containing special characters into forms that are accepted across all the platforms it runs on.
These become part of the name without conversion.
The Empty String
The resulting filename is %.
ANSI Punctuation Characters
Each character listed is converted to the sequence shown (chosen to be easily remembered). Punctuation characters not in the table become part of the name without conversion.
||Period (only used for the leading or trailing character of a file name)
ANSI Control Characters
Each of the control characters is converted to its own sequence as shown here:
|Chars 1 to 26
||%^A to %^Z, respectively
|Chars 27 to 31
||%^1 to %^5, respectively
The Latin-1 characters shown in the table are converted to their respective sequences. Characters above 159 are printable characters and are left unchanged.
|Chars 129 to 154
||%_A to %_Z, respectively
|Chars 155 to 159
||%_1 to %_5, respectively
Files whose names begin with any of the following sequences followed by a period will be prefixed with %M (Microsoft):
COM1 through COM9
LPT1 through LPT9
By default, the CREATE.FILE
command creates INODE files, in which each global node represents one item. An INODE file stores each record in a global node. Therefore, in an INODE file each record
cannot exceed 3.5 million characters in length. INODE files generally provide superior query and read/write performance.
command can also create ANODE files. In an ANODE file, each field of each record is stored as a global node. Therefore, in an ANODE file the limit for each field in each record
can be 3.5 million characters. ANODE files can be extremely large. ANODE files are especially useful when writing directly to the global. However, maximum string length restrictions may limit the usage of extremely large ANODE files. For example, the MVBasic READ
command may encounter a maximum string size when reading an extremely large ANODE file.
can create an ANODE file by specifying the ANODE option. By default, these commands creates both DICT and DATA files as INODE files. If you specify the ANODE option, the DATA file is created as an ANODE file, but the DICT file is still created as an INODE file. You must explicitly specify DICT ANODE to create both DICT and DATA as ANODE files.
Select lists are stored as ANODE files.
&SAVELISTS& and &PH& files are created as ANODE files by default. The &HOLD& file can be created as an ANODE file.
When CMQL is used on an ANODE file, only the first 100 attributes are available. This permits the listing of the files and a sample of the data but prevents CMQL from trying to read in very large items.
An index cannot
be an ANODE file.
create a class on an ANODE file.
Create an INODE file with:
Create an ANODE file with:
MV:CREATE.FILE CARA ANODE
to enter the same two records in each file, displayed below:
0003 Mini Cooper
0003 Mini Cooper
If you examine the data on disk, you can see the difference.
For the INODE file, each record is stored in a global node, with fields delimited by field (attribute) marks.
For the ANODE file, each field of each record is stored in a global node, where the second subscript is the field number.
Caché associates locks with the file variable. This differs from most MultiValue implementations (except UniData) which associate the lock with the file. Locking is affected by the transaction state; see also the section Transaction Lock Handling
in this book.
For example, consider the following sequence of events:
A main program opens a file and locks a record in it.
The main program calls a subroutine, passing the file name but not the file variable.
The subroutine uses the name to open the file using a local file variable, locks the same record in the file, performs some calculation, releases the lock, and returns to its caller.
When the subroutine returns control to the main program, the lock set by the main program is still in force. It is associated with the file variable in the main program.
In this sequence, however:
A main program opens a file.
The main program calls a subroutine, passing the file variable as an argument.
The subroutine uses the file variable argument to lock a record in the file, performs some calculation, and returns to its caller.
When control returns to the main program, the lock set by the subroutine is still in effect because it is associated with the file variable passed as the argument.
The same principle applies to a single program which opens the same file multiple times using different file variables. Lock operations using one file variable do not affect locks taken using a different file variable. Thus, when a program locks the same item through two different file pointers, the second lock isn't blocked, because it is taken by the same process. (Some MultiValue implementations DO block such a lock.) However, each lock must be separately released.
© 1997-2019 InterSystems Corporation, Cambridge, MA