More PRO arguments:
If "use strict;" is used (and I use it all the time), you get error
checking, which will save lots of debugging time. Of course, you get error
checking in PL/SQL but not much in shell scripts. It's easy to waste lots
of time trying to troubleshoot a typographical error in a
I am in a similar position - migrating huge amounts of shell scripts, sql
scripts and PL/SQL programs to Perl/DBI (Oracle - Data warehousing
environment)
Apart from the PRO's already mentioned, I find that Perl/DBI reduces the
number of lines of code considerably, and also the number of program f
- Original Message -
From: "Wilson, Doug" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, June 05, 2001 07:34
Subject: RE: Marketing DBI
> PRO:
>
> 1) We have alot of SQL*Plus scripts here, DBI is not even officially
&
PRO:
1) We have alot of SQL*Plus scripts here, DBI is not even officially
installed. The scripts have to write to a log file, then the log file
has to be grep'ed for errors and other output which to me seems like a
real hack. You can't easily make decisions to do 'something else' in the
middle of
I would have to go with the ease with which you can do almost anything in
perl in a very short amount of time. I recently used DBI, CGI, and
SNMP::Util to query devices(routers, switches, etc) live store the results
in a database and display it dynamically on our intranet in a matter of a
few hou
Peter,
You might also bring up some of the capabilities that perl/DBI
will provide that they can not do with SQL*Plus.
1) access to multiple database instances within the program
2) Different DB access levels within a program - security
3) Much easier integration with web services
4) perl/DBI can
Your best point of approach might be the shell script wrappers. As a
compiled language, Perl is much more reliable; an error in a shell script
only shows up when that line gets executed which could be months after
deployment.
You can also institutionalize local oddities in Perl libraries. For
i
The biggest way I've sold it is related to your "real language"
comment: Perl has so many good existing packages at CPAN that
I can very quickly throw together quick "real" apps. that not
only do the database work, but also send the data (e.g., via ftp
or http), notify people via email (Mail::S
