radagast has asked for the wisdom of the Perl Monks concerning the following question:

I am currently trying to set up scripts using DBI and ODBC using the OpenLink driver. DBI needs some of the Openlink paths to be defined and I would like to do so in the context of my script, not globally. Right now, if I create my paths in a shell script and from the shell run my perl program, it works. However, when I try to load the paths as $ENV, even though they load successfully, I am getting problems. I tried hardcoding the $ENV variables as in:

$ENV{DBI_DSN} = "path"

and I can verify that these are being passed. I even put all these $ENV{..} assignments in a seperate file and evaluated the file's contents and the variables pass. Is there some detail I'm mssing?

Replies are listed 'Best First'.
Re: $ENV question
by lhoward (Vicar) on Nov 29, 2000 at 16:44 UTC
    This is only a guess... but I suspect that they are being set too late in your program. I've seen this sort of problem before where env vars set inside the program don't take effect when it relates to code that is liked in at run-time unless they are put inside a begin block. Try enclosing your statments to set your ENV values in a BEGIN block like this: 
    BEGIN {
  $ENV{DBI_DSN} = "path";
}

    [download]
    or if you want to be paranoid: 
    BEGIN {
  unless ($ENV{BEGIN_BLOCK}) {
    $ENV{DBI_DSN} = "path";
    $ENV{BEGIN_BLOCK} = 1;
    exec 'env',$0,@ARGV;
  }
}

    [download]
[reply]
[d/l]
[select]
Re: $ENV question
by PsychoSpunk (Hermit) on Nov 29, 2000 at 23:21 UTC
    Here's what I've found while using the Openlink ODBC driver and DBD::ODBC:

    I put copies of .odbc.ini into the ~/ of the user that runs the script. (i.e. - there is a copy in nobody's ~/ if you're running from a web server where nobody is the User)

    You must have a copy of udbc.ini in /etc or else it doesn't work. I need to complain to Netrista that the free version from iodbc.org doesn't contain a copy of that.

    You must set $ENV{ODBCHOME} to the location of Openlink. This is not the lib directory but the parent Openlink directory.

    If you don't define your DBI_DSN, DBI_USER, or DBI_PASS environment variables, you can provide that information on the connect string.

    DBI->connect('dbi:ODBC:dsn', 'user', 'pass', {...});

    If you're having problems with large strings coming from the database, turn on LongTruncOk in the DBI arguments (i.e. - {LongTruncOk => 1}).

    Some general rules about the DBI. Use RaiseError during debug mode. It is great. Use a trace level of 3 if RaiseError is not helpful enough. Before DBI->connect: DBI->trace(3); Get a copy of the cheetah (Programming the Perl DBI).

    Good luck, and have fun. :)

    Update: Forgot to mention about your $ENV{DBI_DSN} = 'path'. That's not right. 

    $ENV{DBI_DSN} = 'dbi:ODBC:dsn';
$ENV{DBI_USER} = 'user';
$ENV{DBI_PASS} = 'pass';
$ENV{ODBCHOME} = '/usr/local/openlink';

    [download]

    That will get you further. :)

    ALL HAIL BRAK!!!

[reply]
[d/l]
[select]
Re: $ENV question
by dws (Chancellor) on Nov 30, 2000 at 01:52 UTC
    PsychoPunk's answer seems to be on point for your problem. The problem of (not) side-effecting the process environment by modifying %ENV has been discussed in a separate thread. See here for one answer.
[reply]
      My own particular solution about the $ENV{ODBCHOME} is to have the script set it. It's the only %ENV setting I mess with on runtime. My reason for doing this is my scripts can use multiple DBMS and so I actually set $ENV{$DBTYPE} in order to provide the DBD driver the environment that it will need when I need it. Plus, setting the necessary environment variables may come in handy when you don't know whether a given user will have it set when they wish to run your code.

      Especially in this case, you don't really need $ENV{ODBCHOME} hanging around when you're not running the script since any system tools such as odbctest (a tool that comes with the Openlink driver) already have it built in.

      ALL HAIL BRAK!!!

[reply]

Back to Seekers of Perl Wisdom