Steve Bertrand wrote:
[snipped due to excessive content]
...
[snip]
Tom was probably thinking of Unix, but same principles apply to other
platforms.
It's also worth noting that whatever application you're using to update
the database may well output something useful to STDOUT and it may be a
simple strategy to examine this output to determine the status of an
operation. If you assign the result of a backtick string to a scalar
variable
my $status = `command`;
then the entire output of the command will be stored as a single string.
If you assign it to an array
my @status = `command`;
then the output will be stored as one line per array element.
The problem here is that I will be dealing with > 500k elements per
cycle (day).
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.
But each of these is a way to check whether a single run of your
application succeeded or failed. Look at what you see on the screen when
you run the command manually. Is there anything in that text that your
program could check for after each run? I would be surprised if there
wasn't.
I hope that's clearer.
Rob
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
http://learn.perl.org/
