[snip] >> I essentially need to know that ALL 500k elements were successful, >> otherwise, I need to know where it broke and where it stopped. >> >> This is a billing situation so it has to be accurate. I'd rather ensure >> (by doing manual double-entry checking) accuracy then having to go >> through potentially 500,000 lines in a log to see what ones went wrong, >> while trying to eliminate the ones that went 'right'. >> >> Or perhaps I understood you wrong. > > I think you did. Unfortunately we are guessing in the dark about what > this external program of yours does when when it fails (or indeed when > it succeeds). Tom suggested checking the exit status or the STDERR > output. I am saying that there's probably also something useful on > STDOUT, which is easier to examine.
The external program is the MySQL client binary. I know the queries are clean (it will run manually with no problems). Here is what I'm doing: - taking all rows for $today from table1 - deleting any possible erroneous rows from $today from table2 & table3 - grouping by fieldX and fieldY and inserting into table2 - updating (renaming) fieldY values based on it's content in table2. fieldY's content will be renamed into one of three names, based on the number range it contains (208.70% == 'dialup' 65.70 == 'dsl' etc) - taking all rows from table2, grouping them based on fieldY (name), and inserting into table3 > But each of these is a way to check whether a single run of your > application succeeded or failed. Indeed. More importantly as stated above, I need to be sure that all records (or a random statistical subset) succeeded. mysql will succeed even if there were a large chunk of records that had erroneous entries in the field I am looking at with a WHERE clause. I know if I Perl-ize this, I'll be able to produce myself a report of any sort of statistics I want from the run 7 ways from Sunday. That is exactly what I plan to do instead of worrying about it. Thanks for the replies. All the thought that went into this got me thinking on other tracks for other code, but that's for another day. Steve -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/
