Simple need. Simple interface. Don't keep on rewriting the connect code. Don't duplicate information.

I agree fully. I adopted this solution whch lead to inteminable arguments with my colleagues which I grew weary of and relented. The problems that occured by moving the data into an exporting module were many, and I sorely regretted giving way.

So to reiterate. Create a class that represents an open connection to the database. Simple, effective, and minimizes code waste.

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

Well I cheated. I hid the data from the module that gave out the database handles into a config file, and I reexported that data to one other module.

Turns out that some bulk database transfers were orders of magnitude faster with bcp, so I really did need the name/password. But only in one controlled situation...

I think the best choice you mentioned is definitely the "functions file" method (a module even?) with a function returning the proper settings. Personally, I wouldn't hard-code global values into the code though, at least not if they're likely to ever change. Use a separate configuration file (e.g. a text file) instead. This way once you get your code working you don't have to go back and change it just because you moved the database.

Hope this helps!

  # Config Module
  package My::Config;
  use strict;
  use vars qw(%c);
 
  # Create a hash containing our config data 
  %c = 
    (
     dir => {
             cgi  => "/home/httpd/perl",
             docs => "/home/httpd/docs",
             img  => "/home/httpd/docs/images",
            },
     url => {
             cgi  => "/perl",
             docs => "/",
             img  => "/images",
            },
     color => {
               hint   => "#777777",
               warn   => "#990066",
               normal => "#000000",
              },
    );

 
  # Main program code (in a seperate file of course)
  use strict;
  use My::Config ();
  use vars qw(%c);
  *c = \%My::Config::c;
  print "Content-type: text/plain\r\n\r\n";
  print "My url docs root: $c{url}{docs}\n";
[download]

Wouldn't it be just as simple to have the configuration module return a hash reference via a function? That way, the program is somewhat easier to read:

use strict;
use My::Config 'GetConfig';

my $config = GetConfig();
print "Content-type: text/plain\r\n\r\n";
print "My url docs root: $config->{url}{docs}\n";
[download]

buckaduck

My god. NO!!! It's the dreaded "me too" post!

I like a combination of these ideas.

Maintain a module that will give you the open handle, that uses a config file to grab it. That way you can play all the games you want with specifying config files and datasources hot.

We have a bunch of code that we all of a sudden needed to link to multiple databases (*sniff* *sniff* legacy system? Yep, the tracks are still warm.) And that approach saved our collective posteriors.


$.02

- V

If you're accessing a database and don't want to prompt for a username and password every time, you can keep the username and password information in the configuration file.

Be sure to set the permissions of the configuration file so that it is only readable by a certain group (It's probably best to have a new group created for this purpose only). Set the group ownership of your scripts to this group id, and make the scripts run setgid (chmod g+s filename). You can set this up easily if you have administrative priveleges on your computer.

buckaduck