Begin {$NEW{SYBASE}='Sybase';}

I think that should probably be:

BEGIN { $ENV{SYBASE} = '/sybase'; }
[download]

Case (and spelling!) is important in these matters :)

"The first rule of Perl club is you don't talk about Perl club."

For Apache, you can use the 'SetEnv' directive. For mod_perl, there is a 'PerlSetEnv' configuration directive.

Anyway, maybe you meant $ENV{SYBASE} = '/sybase' ? (%ENV instead of %NEW).

You may have to do this anyway.

In my experience, setting the environment variable with $ENV{SYBASE}='whatever' within a BEGIN block sets it too late, at least when using DBI with DBD::Sybase.

I've had some success with something like this (which, BTW, makes a program nearly impossible to debug)

BEGIN {
  #need this so you don't recurse indefinitely:
  if ( not exists $ENV{SYBASE_SET} ) {
    $ENV{SYBASE_SET} = 1;
    $ENV{SYBASE} = 'whatever';  # set the variable
    exec $0;                    # exec self with new env
    ## NOT_REACHED
  }
}
[download]

This approach works in cases where the modules one is 'use'ing have their own initialization inside BEGIN blocks.

Edit: You also should make certain that this BEGIN block preceeds any uses or requires which may bring in such modules.

dmm

You can give a man a fish and feed him for a day ...
Or, you can teach him to fish and feed him for a lifetime

Hmmm - that doesn't seem quite right. I suspect that you are confusing the SYBASE env. variable with LD_LIBRARY_PATH.

When working with these environment variables it's always important to remember when theyaare needed.

DBI does not load the DBD::Sybase code when you issue a "use DBI". So it follows that you only need to set the SYBASE env. variable before you call DBI->connect() - unless you have a "use DBD::Sybase" statement, in which case you do need to have $ENV{SYBASE} defined and set correctly (because DBD::Sybase runs some Client Library initialization code when it gets loaded and that code needs the SYBASE env. variable to be set correctly.)

The LD_LIBRARY_PATH variable, on the other hand, does need to get set before the script starts. You can't affect the shared library search directories for the current process (at least not on the platforms that I am aware of!)

Michael

we've had similar problems where i work with trying to get access to the campus' main DB2 server. apparently, when they installed it, they didn't put all the libraries in the right place and the perl executable can't find what it needs. although the Begin trick seems like it should work, access to the libraries are apparently needed even before that is executed.

the ugly workaround that we've been stuck with while trying to convince the sysadmins to set it up correctly is to wrap the script in a shell script that sets the environment variable and then calls the perl script.

i hope you can find a cleaner solution to your problem.

anders pearson

If you are using Apache the easiest way to do this is to add a SetEnv directive to your httpd.conf file.

You can also rebuild Sybase::CTlib and enable the EMBED_SYBASE option (see the CONFIG file). This option adds a hard-coded $ENV{SYBASE} setting in the CTlib.pm file, which is usefull in some situations.

Michael

I am using Sybase::Ctlib on SunOS 5.6.It's a corporate machine so I can't touch the CONFIG file or the CTlib.pm file. I am using your documentation for my calls.I set my first statement (after defining the perl path ) to BEGIN{$ENV{SYBASE}='/sybase';}and it worked. I have another question which you would be the best person to answer since sybhelp is telling me that it can't load .CTlibHelptextMsgs (and I can only find *TextMsgs files for desedit_dce,sqlupgrade,sqlloc,srvbuild and sybsetup). I am getting the following error:

Open Client Message: Message number: Layer=(1) ORIGIN=(1) SEVERITY=(1) NUMBER=(159)
Message String: ct_cmd_drop():user api layer: external error: This routine can be called only if the command structure is idle.

I can not find any documentation on ct_cmd_drop(). What type of logic error should I be looking for in my code?

ct_cmd_drop is usually only called when you close your connection (i.e. when the database handle is destroyed). The error message means that when ct_cmd_drop() was called there were still results pending, which usually points to an incorrect fetch loop in your code.

So I suggest that you take a look at your code and make sure that you process all the data that is returned by the server, or that you call ct_cancel() if you want to throw the remainder of the results away.

Michael