Posted by Bob A on April 21, 2014 at 13:07:12:
Had a file with 3 keys which were also Extended Keys
when it encountered a key error, the program attempting to purge this file (by sifting out old records) fell over on the first bad key, which happened to begin with 20 blanks.
seem to have gotten two different results for Key Check...
QTILITY check seems to die on the first bad key with E9a (just like COMET/32 program
CometEx check finds the 13 bad keys
just for grins (as they say in Da Bronx), I copied the file selecting all keys beginning with blanks. Chugged for a while but ended successfully... then I used Key Check on the OUTPUT file.... no runs, hits, errors.
so my question(s) are these:
1) since my IB program does a CLEARFILE, does this have any bearing on the problem (found some posts from November 2013 about another E9A problem with CLEARFILE http://support.signature.net/messages/20362.htm)
2) does it matter which Key Check I do for extended key files with multiple keys, or was this just happenstance that CometEx worked
3) since it seems to do an implicit build, what is the cost to re-build files using Copy in CometEx rather than Key Build in CometEx
4) is the trapping of errors in CometEx done at the C++ level, and is that why the trap works there but I can't get it to work in Comet/32 MTB/IB
Thanx
Bob "A"
P.S. I'm running 480 on my TEST system and 479 on my PROD system... people want 480 shaken down on the TEST system before porting over to the PROD system (can't complain about that)
Each file can be a maximum of 1MB in length Uploaded files will be purged from the server on a regular basis.