Posted by Grant Foraker on September 04, 2009 at 14:20:01: Uploaded files: 1
A few weeks back I posted an updated version of the old QMAINT program. If you don't know it, it uses #FILES as a driver for a general purpose maintenance program. Most of the time it's better than MAINT or the maint option in CometExplorer as the fields are seprate and labeled. I found it a handy tool and wanted something that would work with #CFILES.
So, I'm throwing out version 16.0. "16" is for Comet16. ".0" is user beware. But you knew that already. The Comet32 version will come later. Hopefully.
Feature/Improvements:
---------------------
Works with #CFILES
Key Length upto 199 - old was 64
Record Length upto 8000 - old was 254
Numeric Fields up 16.16. - old was 16.8
String Fields upto 199 - old was 50
Both types of Keyed files - old didn't support Extended
No image file support - old supported image
No command processer - old support command files
1) The 199 is a limit in CosWin's ListView processing.
2) Image files are going away so no point of coding them in even though #CFILES allows Image files (for now). QMAINT supports image files.
3) QMAINT had command files, something like $ files. I never used the feature. Most of my maintenance programs are multi-filed and I'd never make anything like this into a production program.
4) Keyed only. I have very few Sequential files in my customer systems. Don't see a need to add Sequential support.
Installation:
-------------
The attached ZIP files uses QDIR.CPY. Use DOSCOPY to copy the OBJ and DLL into any directory you want. This will "register" the DLL into Comet. The programs use QDIR to find the location of the DLL. This is different than the example used in Brian's sample programs. This allows the DLL to be in a separate DIR and not in the directory of the running OBJ. I also like to be able to see the Date/Time of the DLL from inside Comet.
Programs:
---------
CMAINT - File and Field selection dialog
CMAINTM - Record and Field Maintenance dialog
CMAINTS - String field dialog
CMAINTN - Numeric field dialog
CMAINTK - Key entry dialog
Issues:
-------
Extended keyed files are supported for the Primary Key. When you add or Duplicate a record, the new key is propagated into the data location specified by the Primary Key. Currently nothing is done about the secondary keys. "Add" records get all their fields blanked out (even numeric) before the fields are displayed. "Duplicate" records retain their data (except for the key propagation). This complicated because, during CMAINT, you may have only selected a few of the fields in the record and you may not have access to the data fields that constiture the secondary fields.
Also, I can see a problem if you define a key field multiple times in the data record. For instance ...
CustomerRec: FORMAT_
@(0);CNBR$;_ ! LENGTH 5 ! PRIMARY KEY
@(25);CNAME$;_ ! LENGTH 25
.....
@(300);CNAME$;CNBR$ ! SECONDARY KEY
For pre Extended Keyed files, on "Add"s and "Duplicate"s, I'm presuming that the key begins in 0. Convert all your files to Extended :)
This again raises the argument about how secondary keys are defined. I've always argued that they be "virtual". You should be able to define a key as (5,25) + (0,5) instead of having the data in the file twice.
Have fun, play carefully. Let me know what you think.
Each file can be a maximum of 1MB in length Uploaded files will be purged from the server on a regular basis.