The first step you must perform is to scan the existing disk-based catalog, which creates a series of intermediate files, locating the existing data files in the catalog. These files will be used in the second stage, when the deployable files are produced.
To scan the catalog:
mfdbcatc -s -c <catalog file>
Where: <catalog file> is the existing catalog file. This results in a series of intermediate files: a number of files prefixed R_n.dat, and some configuration files.
The configuration files are relative.cfg, static.cfg, environment.cfg and fileshare.cfg, and are used to deal with the different location types that may exist in the catalog. Before you run the second stage of the process, you can edit these files to affect the final deployable files.
This configuration file deals with catalog entries that are relative to the location of the configured catalog folder. The contents will look something like this:
0001:<CATALOGFOLDER>/DATA/ 0009:<CATALOGFOLDER>/DATALIB/
Such entries indicate that the catalog has two sub-folders within the catalog folder location that contain data files: DATA and DATALIB.
At this point, you could edit these entries if you wanted to change the structure of your catalog once it is deployed to a database; for example, to move files from the DATA folder to the DB_DATA folder within <CATALOGFOLDER> once they are deployed, edit the file as follows:
0001:<CATALOGFOLDER>/DB_DATA/ 0009:<CATALOGFOLDER>/DATALIB/
Alternatively, to store the files currently in the <CATALOGFOLDER>-relative DATA path, to a static location called DB_DATA on the server myhost, in the datastore mydatatable, edit the file as follows:
0001:sql://myhost/mydatatable/?type=folder;folder=DB_DATA/ 0009:<CATALOGFOLDER>/DATALIB/
You could even move the <CATALOGFOLDER>-relative 'DATALIB' path to a local disk-based directory location; although this is not really what the utility is intended for:
0001:<CATALOGFOLDER>/DATA/ 0009:C:\DATAFILES\DATALIB\
The static configuration file deals with those files that are referenced using a static (hard-coded) location. This type of file is slightly different in that it won't show where the files are currently stored, but will show a suggestion of where theses types of file would be stored once they are deployed.
The suggested location is a simple extrapolation from the current path, with placeholders for database identifiers. The contents could look something like:
0001:sql://{host}/{instance}/{datastore}/?type=folder;folder=TEST_DATA_/
This result indicates that the scan identified data files in /TEST/DATA/. The identifiers {host}, {instance}, and {datastore} will be replaced with values specified during the update (second) stage, unless they are changed in this configuration file. If you edit the placeholders in this file, it ensures that the files currently in /TEST/DATA/ go to a specific location in a specified database:
0001:sql://MYHOST/MYSTORE/?type=folder;folder=MY_DATA_/
You can also move them to a different, relative location:
0001:<CATALOGFOLDER>/MY_DATA_/
Or to a static disk location (again, not really what this utility is intended for):
0001:D:\ANOTHER\DISK\MY_DATA\
Sometimes the file location is relative to the value of an environment variable. The value of the variable is required to resolve the location of the source. This value can also serve as the destination location too.
This configuration file is more complex than the previous file types. When using an environment variable for part of a file location, it looks something like this:
$MYLOCATION/DATA/
At run time, the environment variable $MYLOCATION is expanded, and the full path is built from it value. For example, if MYLOCATION=C:\TMP\, the source location resolves to C:\TMP\DATA\.
The deploy stage also needs to be able to resolve the value, both to locate the source and also to deploy to the database. By default, using the above example, the configuration file contains an entry similar to:
0001:$MYLOCATION=[<ENV-VALUE>]DATA\,<CATALOGFOLDER>/DATA_/
The comma separates the source and destination parts. If <ENV-VALUE> is left as it is, the mfdbcatc utility checks for the value of the MYLOCATION environment setting when the update/deploy stage is run. You can also edit the configuration file to use a specific value:
001:$MYLOCATION=[C:\TMP\]DATA\,<CATALOGFOLDER>/DATA_/
Alternatively, you could edit the file to use a fixed location:
0001:C:\TMP\DATA\,<CATALOGFOLDER>/DATA_/
Either of these edits will affect where the files to deploy are located.
The destination part (the entry after the comma) suggests deploying the files into a catalog-relative location (in /DATA_/). You can change this to any of the entry types discussed earlier, which will modify the new catalog entry to reflect where the file has been deployed. For example, to deploy to another environment variable entry:
0001:MYLOCATION=[C:\TMP\]DATA\,NEWLOCATION=[sql://myhost/mydata/?type=folder;folder=DATA/]MOREDATA/
This deploys files found in C:\TMP\DATA\ to sql://myhost/mydata/?type=folder;folder=DATA/MOREDATA/, but the entry in the new catalog will refer to $NEWLOCATION/MOREDATA/.
Alternatively, you can just deploy to a static location:
0001:MYLOCATION=[C:\TMP\]DATA\,sql://myhost/mydata/?type=folder;folder=DATA/MOREDATA/
The difference being that here the catalog directly references sql://myhost/mydata/<filename>?folder=DATA/MOREDATA/ for the file.
You can also deploy to a new static disk location:
0001:MYLOCATION=[C:\TMP\]DATA\,C:\TMP\NEWDATA\
The content of this file will look something like this:
0001:$$FSSERVER/DATA/,<CATALOGFOLDER>/FSSERVER_DATA_/
By default, it suggests a catalog-relative destination. Again, you can change this to a specific location, as discussed for the previous file types. This file type follows the same editing rules as those for environment.cfg.