Operational Differences between MultiValue and Caché
File-Related Issues
[Back] [Next]
   
Server:docs1
Instance:LATEST
User:UnknownUser
 
-
Go to:
Search:    

Name Mangling
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.
Alphanumeric Characters
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.
Character Replacement Mnemonic
% %%  
* %A Asterisk
\ %B Backslash
: %C Colon
" %D Double quote
> %G Greater than
< %L Less than
. %P Period (only used for the leading or trailing character of a file name)
? %Q Question mark
/ %S Slash
| %V Vertical bar
(del) %Z  
ANSI Control Characters
Each of the control characters is converted to its own sequence as shown here:
Character Replacement
(nul) %^0
Chars 1 to 26 %^A to %^Z, respectively
Chars 27 to 31 %^1 to %^5, respectively
Latin-1 Characters
The Latin-1 characters shown in the table are converted to their respective sequences. Characters above 159 are printable characters and are left unchanged.
Character Replacement
128 %_0
Chars 129 to 154 %_A to %_Z, respectively
Chars 155 to 159 %_1 to %_5, respectively
Prohibited Names
Files whose names begin with any of the following sequences followed by a period will be prefixed with %M (Microsoft):
ANODE Files and INODE Files
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.
The CREATE.FILE 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.
Example Showing the Difference Between INODE and ANODE Files
Create an INODE file with:
MV:CREATE.FILE CARI 
Create an ANODE file with:
MV:CREATE.FILE CARA ANODE  
Use ED to enter the same two records in each file, displayed below:
MV:CT CARI 1 2 
1 
0001 1965 
0002 Ford 
0003 Mustang 
0004 Red        

2 
0001 2008 
0002 Austin 
0003 Mini Cooper 
0004 RedýBlack 
MV:CT CARA 1 2 
1 
0001 1965 
0002 Ford 
0003 Mustang 
0004 Red       

 2 
0001 2008 
0002 Austin 
0003 Mini Cooper 
0004 RedýBlack 
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.
MV:[zw ^CARI 
^CARI=$lb(0) 
^CARI(1)="1965þFordþMustangþRed" 
^CARI(2)="2008þAustinþMini CooperþRedýBlack" 
For the ANODE file, each field of each record is stored in a global node, where the second subscript is the field number.
MV:[zw ^CARA 
^CARA=$lb(1) 
^CARA(1,1)=1965 
^CARA(1,2)="Ford" 
^CARA(1,3)="Mustang" 
^CARA(1,4)="Red" 
^CARA(2,1)=2008 
^CARA(2,2)="Austin" 
^CARA(2,3)="Mini Cooper" 
^CARA(2,4)="RedýBlack" 
In the INODE file, MultiValue field values are delimited by fiedd marks. In the ANODE file, field four with Red and Black shows a value mark (see the section Dynamic Arrays in the Caché Multivalue Basic Reference for a table of dynamic array delimiter characters.
Locking Behavior
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:
  1. A main program opens a file and locks a record in it.
  2. The main program calls a subroutine, passing the file name but not the file variable.
  3. 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:
  1. A main program opens a file.
  2. The main program calls a subroutine, passing the file variable as an argument.
  3. 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.
Note:
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.