From CometWiki

CFILES is the replacement for DbMgr. It allows you to maintain your #CFILES Data Dictionary which is used by the Comet Reporter.

• Sort display by any column
• Double-click a field's attribute to edit it right in the listview
• Double-click an expression's name to display/edit it
• Right-click a field to rename it, delete it, or edit a calculation definition
• You can undo your changes by clicking "Revert to Saved"

Utilities

• Generate #CFILES
  • Convert from old #FILES or .d00 files
  • Select a range of files to convert
  • Merge with existing #CFILES or replace it
  • Produces a report of errors found in original definitions
• Import or Export all or part of your #CFILES definitions
  • Transfer done via text file
  • Import option to merge with existing definitions
• Import file definition from an IB FORMAT statement
  • Choose FORMAT from .ibs, .inc. or CED file
• Generate IB include file from #CFILES definition
  • Field declarations in order by name or position
  • IB variable names automatically built from #CFILES fieldnames if needed
  • Record position qualifier added if overlapping field or gap in record layout
• Convert CED Reporter spec files to .ibr files
  • Select a range of files to convert
  • Produces a report of errors in Reporter statements
• Search #CFILES for definitions by actual data file name
• Print the #CFILES dictionary
  • Select a range of files to print
  • Optionally include field and link information
  • Choose field name or record position order for field information
• Output data from actual file in XML format
  • Option to include data from linked files
• Output data from actual file in CSV format

Pre-release design discussion

One of the problems DbMgr tried to solve was what to do about overlapping field definitions in a file. Consider this file. This is an actual file definition from a real Comet user:

The fields are sorted in position order. Look in the "Exp" column. This column indicates if the field is a simple field (F) or an expression (E). An (O) indicates that the field overlaps at least one other field.

These fields present a couple of challenges to CFILES:

• When generating an include file from the definition, position modifiers must be used in the FORMAT to make sure the fields end up in the right positions
• When adding or removing a field CFILES has trouble knowing if it should modify the positions of subsequent fields also.

The problem as I see it is that while CFILES can identify which fields are overlapping it can't guess which field it should consider to be the dominant one. In the example above, notice that field key.to.apf10 overlaps co.no and vend.no. If you were to make an include file for this file definition you'd probably opt to use only the co.no and vend.no fields in the FORMAT and skip the key.to.apf10. How can CFILES know to do this? Likewise, if you were to delete key.to.apf10 from the field definitions you probably don't want all the subsequent fields shifted over because co.no and vend.no are still there - or should it delete those fields also?? You see it gets tricky.

Dates are another very common place for overlapping definitions. invc.date.ymd above demonstrates this. It overlaps the individual fields for the month, day, and year segments of the date. Perhaps we need a way for you to indicate which field is the dominant one. What do you think?

Another problem is when gaps in the record are detected. When an include file is generated a positioner is required to make sure the field after the gap is in the right place. And, gaps are problematic when inserting new fields. Do you want to use up the gap or shift the gap over as if it was a field?