Creating and Deleting Files
As a general rule, files that may be accessed from the operating system level must be directory files and all other files should be dynamic files. Dynamic files give best performance but records cannot be accessed from outside of QM.
QMBasic source programs are normally stored in directory files. Dictionaries are automatically created as dynamic files regardless of the type of the associated data file as a directory file dictionary could cause severe performance degradation in query processor commands.
Files are created using the CREATE.FILE command which normally creates both a data and dictionary portion for the file. Either may be created individually by use of the DATA or DICT keywords. Dictionary portions are not required for files used to hold QMBasic source programs or include records.
The CREATE.FILE command creates the file and also writes an F-type record to the VOC. If the file is to be accessed from more than one account, this F-type record may be duplicated in the other accounts, changing the pathnames in fields 2 and 3 to include the drive and directory components as necessary. A better method is to use Q-type VOC entries for remote file pointers.
The data portion of a file is created at the specified or default minimum modulus size and with no records. The dictionary portion has a single record, @ID, added to it to represent the record key.
Files may be deleted using the DELETE.FILE command. The DATA or DICT keywords allow deletion of just the appropriate portion of the file.
Where the file's pathname in the VOC includes drive or directory components, the DELETE.FILE command assumes the file to be in some other account and prompts for confirmation that it should be deleted. If the file is to be retained but the reference to it from the current account is to be deleted, use the DELETE command to delete the VOC record.
Rules and Restrictions
The QM file system uses the underlying operating system file structures to store its data. This imposes some rules on how the operating system level files should be managed.
On Windows XP and later systems, use of mapped drives can assign different physical locations to the same drive letter for different users or conversely lead to a file having different pathnames in different processes. This will cause serious problems to QM as it is impossible to identify a file uniquely. In particular, the locking system is likely to become unreliable, including the low level internal locks that control structural integrity of files.
All QM users should use the same mappings. For users entering QM via a network connection, including connections looped back to the same machine, the NET USE command may need to be used to create the drive mapping. This can be included in the LOGIN or MASTER.LOGIN paragraphs in the form
SH NET USE X: \\SERVER\DIR password /USER:username
where X: is the mapped drive letter and \\SERVER\DIR is the target directory to which X: is to be mapped.
Similarly, use of chroot on non-Windows systems destroys the uniqueness of file names. Although this may work in some cases, it can lead to ambiguities that will cause QM to fail in unpredictable ways. Use of this command is at the user's own risk.
Where the mapped drive would reference another system running QM, the QMNet network file access mechanism should be used instead. This guarantees correct concurrency control between the two servers.
Systems other than Windows allow a file to be renamed or deleted while it is in use. This action is likely to cause QM to fail and should not be used.
In directory files, the internal field mark character is replaced by the ASCII newline character when a record is written to disk so that fields appear as lines if the record is viewed, edited or printed from outside QM. Conversely, ASCII newlines are converted to field marks on reading a record. Mechanisms are provided in QMBasic (see the MARK.MAPPING statement) to turn off this translation when handling binary data.