The more package-oriented way is probably to use the DBI package at
the top of your script. Perhaps you could do something like this:
#!/path/to/perl
use strict;
use warnings;
use DBI;
# connect to database
my $dbh = DBI->connect('DBI:mysql:db_name','user','password')
or die "Could not connect to database! : " . DBI->errstr;
Now you can use the $dbh variable locally. This would make your life
pretty easy and it works with 5.8.6. It makes you life easy because
you can diagnose database connections in the script you are writing
and not in some other far off script you didn't write. It also allows
you to specify very granular variables like a specific user who may
only have "SELECT" rights to the database which is one way to
increase security. Or you may have to change the password or even
change the database driver. All those things are doable with DBI. Do
a `perldoc DBI` to find out more.
The latest (stable) version of perl is 5.8.8 and soon 5.10 is due to
appear soon, I don't understand why Apple ships such old versions of
perl. Bad Apple.
Jeremiah
On Oct 5, 2007, at 4:06 AM, Sherm Pendley wrote:
On Oct 4, 2007, at 6:57 PM, Michael Barto wrote:
I am working with an old Perl Library (program module) written in
Perl4 and Perl 5 depending who was "hacking the code". My program
that calls it, uses -w and strict and has identified many syntax
errors and so forth in the old library which I fixed. My problem
is that this library needs two variables passed as globals to it
to use in one of the subroutines, One of them is the $dbh variable
created when the database is open. Another is a hash. Both these
variables were initiated at the Main top most level of the program
with "my". Unfortunately, this causes an error and the libraries
does not see the global.
My() isn't package scoped, it's file scoped.
Our() is package scoped, so add a package declaration at the top of
each of your files, and in each of them declare $dbh with our.
Basically, like this, at the top of each file that uses the shared
variable:
package SuperNifty;
our $dbh;
Alternatively, you could define $dbh in a module, and include it in
the module's @EXPORT or @EXPORT_OK, so that an alias to it is
exported into the module user's namespace.
sherm--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net
