Questions and Answers

This section is intended to provide information on various questions which have come up in the use of this tool.

• Q: Originally, the compile phase expected the empty schema files to be available single user. This is a problem if I try to use my regular development DB. A: As of 0.59 You can change this behavior if you want by the use of the chDataBaseConnectParams variable.
• Q: Why use a schema .df instead of just reading the empty schema holder DBs? A: Some people may want to decouple the compile component, so I didn't want one phase to depend on the other. Plus, an explicit .df allows one to include metaschema when needed. But, if there is demand, I will create a version that works from the DBs.
• Q: What if I have a schema where the same table is in more than one DB? A: As of version 0.59 this is supported by providing one .df file for each database.
• Q: Do I need the menu files to use the tool? A: No, only for queries based on Functional Unit.
• Q: Why are there some references to metaschema files showing up with my primary database even though I have supplied metaschama information in DICTDB.df? A: It turns out that file references in validation expressions are forced to resolve against the DB containing the field where they are used. This puts any such references pointing to the relevant application database instead of the Analysis database, so they are not mapped to DICTDB. You can do one of three things: 1) Ignore these references. 2) Add the relevant metaschema files to the .df of the appropriate application database. 3) Modify the MassageMetaDBName method in BuildTableLinks.cls to force mapping to DICTDB.
• Q: Have you considered disconnecting the Analysis database during compilation so that only the application database(s) is(are) connected? A: Yes, I considered it, but on balance have decided against it. One advantage of the current setup is that unqualified references to metaschema resolve to Analysis, making it easy to separate them since in production they could resolve to any database that was currently DICTDB, while qualified references, including those in validation, will resolve to the indicated DB.
• Q: You talked on PEG about possibly allowing multiple source directories, but a single destination directory, which would raise issues about compile order. What about that? A: For the present, I have elected to require N destinations for each N source directories to remove the ambiguity. This seems more powerful in several ways and the difficulty of setting up N destinations is trivial in overall use.
• Q: What if I have a main source directory, e.g., the released version of the code, and then multiple partial source directories with customer-specific code, some of which is versions of released code? A: There are two distinct ways of handling this. One is to make N+1 "images" where one image is the released code alone and the others are one customer's code combined with the release code in two different source directories. The other is to make one image with all of the customer code, each in its own subdirectory. There are currently no special tools for separating out one image from the rest in the latter approach, other than the source directory, of course, but it does allow looking at all versions of the code at once.
• Q: What about aliased buffer names like bfTable for Table? A: COMPILE LISTING will report the name as used in the code, not the table that relates to. The method FindTableName in BuildBlocks.cls can be customized to cover local naming conventions as long as the alias is based on the correct table name with added letters. Otherwise, these will have to be resolved by post-processing.
• Q: What about references to source code in DLC? One doesn't really want to compile those, does one? A: I recommend creating a directory with copies of the needed source code that one includes in the list of the source directories. That way, it can be compiled, XREFed, LISTINGed, etc. as needed to make a complete picture of what the code is doing.
• Q: When I just compile everything in the source directory(ies) I get a lot of errors because of old things left there which are no longer part of the application. Is there a way to ignore those? A: The best solution is to use the compile errors and other tools to clean these up. They are only going to confuse people maintaining the application anyway.