Then the example given, modified to affect STDERR.....

open( STDERR, ">errors.log") or die "Cannot open error log.\n$!";
[download]

The tutorial also suggests that that it can be a clever thing to do to close the STD... filehandle on exit from the program, to force a flush.

END { close STDERR or die "Can't close STDERR.\n$!" }
[download]

In your case, you simply want to redirect STDERR to the OUTFILE file handle. Also listed in the tutorial, you may do this:

open (STDERR, ">>&OUTFILE") or die "Can't redirect STDERR.\n$!";
[download]

Hope this helps!

sub print_error{
    open( OUTFILE, ">> $destination" ) or die "Couldn't open file for 
+reading.$!\n"; 
    print OUTFILE $_[0];
    close OUTFILE
}

my $dbh = DBI->connect( "dbi:ODBC:RETQC_SQL", "sa", "", {RaiseError =>
+ 1, PrintError => 1, AutoCommit => 0} ) or print_error("Unable to con
+nect: $DBI::errstr\n");
[download]

Whilst the above suggestions all solve the problem at hand, if the amount of stuff you're logging out gets significant it's normally a good idea to switch to using one of the many Perl modules that handle logging in a more complete manner.

Amongst the useful capabilities that a decent logging package (I personally use Log4Perl, but many others exist) are:

• Actual details of configuration can be stored either in the program, or a seperate log configuration file. This allows them to be easily changed.

• Pluggable log dispatch system. This allows you to easily set up a situation where, for example, all messages are logged to a file, a database, and printed to screen, but those which are exceptionally important are actually emailled to someone to deal with.
• Capable of having multiple log-files, so you could have your database errors put into one log and any system failures into another if the two types of error were to be handled by different people.
• Ability to change logging levels on-the-fly. By using a configuration file to control the level of detail of logging it's trivial to switch from 'Standard' levels of logging to 'Debug' when things start going wrong, all without needing to edit code and (in the case of Log4perl at least) potentially without needing to restart the service. The logging-levels can even be changed on a per-logfile basis so you could have the extra detail only when needed.
• Keeps code simple and tidy. With the handling of the errorfile etc. kept in it's own set of external modules your own code is kept nice and simple, free of the kind of errorhandling cruft.
• A robust solution, the more used logging modules are used by a considerable number of people so are generally quite well tested and very unlikely to cause problems unless you're doing some very bizarre things with them.
• Simple interface. Most logging systems try and keep things simple, and provide nice drop-in replacements for die, warn etc.

Sorry if it seems like I am randomly soap-boxing, it's just that I noticed that the usability and power of the logging in the more complex systems that I write has been notably improved since I started to use this module.

I have a script that seems to fail when it is scheduled.

I suspect that this is a cron job then. One quick and dirty way of handling this would be in the crontab.

10 * * * * /path-to/your-prog.pl >> /path-to/log 2>&1
[download]

Any STDOUT and STDERR will be captured & written to your log.

A follow-up guess. Your script is failing because it is relying on environment variables that you don't have set right in cron. For a simple way to address that, see Get default login environment.