 
|
|
Considerations for Distributed FilesAlthough jBASE does not restrict you from directly populating part files, records should always be written through the distributed file stub. Be aware that if a record is placed in the wrong part file, and that record is subsequently handled through the partition algorithm, it will be placed in the part file according to the partition algorithms own relentless logic. This will result in the same record appearing in two part files. Once part files are populated, changing the logic of the partition algorithm (or changing the partition method), could have disastrous results. If it is necessary to do this you must pass each record through the new partition algorithm so that it is placed in the proper part file. You must also remember to delete each record from its original location. A distributed file is opened in the usual way. For example, the following statement opens a distributed file called DISTCUST:
By default, when a distributed file is opened, all component part files are opened at the same time. You can defer the opening of all part files by setting the JEDI_DISTRIB_DEFOPEN environment variable. On versions of jBASE prior to 3.3.9, if a record ID resolved to a partition (part file) that did not exist, the process would be trapped to the jBASE debugger with an "Error 22" error message. This behavior has been changed (see patch number PN3_30268) such that a READ from a non-existent partition will take the ELSE clause and a WRITE will be trapped with an 'Error 22' unless the WRITE is supplied with the ON ERROR clause. If you delete a part file then you must also DELETE-DISTRIB to remove the reference from the distributed file stub. You must also modify any user-defined partitioning algorithm. This is detailed in the distributed file example. Distributed files support secondary indexes and triggers at both the distributed file level and the part file level. |