This sample utility contains a dump/load facility. When you run the MKDUMP utility, it creates two ABL procedures: one that dumps a database and one that reloads a database. For example, you can run MKDUMP to create a dump/reload facility for the sports database, as follows:
mkdump sports
The following image shows the files produced by running MKDUMP.
Figure 13. Output of mkdump
The MKDUMP utility runs an ABL procedure, mkdump.p, which creates and compiles two other ABL procedures, filedump.p and fileload.p. The filedump.p procedure dumps the files from a database; fileload.p loads the files into a database.
In addition, mkdump.p creates two directories. The dmpprocs subdirectory contains a database dump procedure for each of the files in the database. The ldprocs subdirectory contains a database load procedure for each of the files in the database. The mkdump.p procedure also precompiles all the procedures it creates. These precompiled procedures may not be appropriate for your use if the deployed database does not have the same name as the original database that MKDUMP was run against.
The MKDUMP utility creates these files and subdirectories in your current working directory. Before distributing them to users, you must move them to your application master directory. You can then supply either the encrypted source or object versions of the filedump.p procedure, fileload.p procedure, and each of the procedures in the dmpprocs and ldprocs subdirectories.
You can modify MKDUMP or any of the mkdump.p, filedump.p, or fileload.p procedures as needed. However, once you have created and perhaps modified the dump/load scripts or batch files, be sure to provide a way for users to use these procedures. You should also provide adequate documentation for users to use the facility.
Note: The dump/load procedures should be considered part of your application. The decision to distribute r-code or encrypted source versions of your application procedures applies to the dump/load procedures as well.
