nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Acesing Oracle from DCT

System

Hi there,
Have you experienced the following issue ?
When launching a script from a prompt session my perl script works properly to access the database but when invoking the script from the DCT is does not work ?

When running the script from within the prompt window it works if I use another perl interpreter , not the one provided with TeamSite 6.1 for Solaris.
Do you have some suggestions about ? we will enter into production this weekend and we are stopped.

Many thanks to all of you in advance.

Best Regards

Find more posts tagged with

Comments

Migrateduser

I've had to deal with this, too... I wonder if you're trying to use some modules that are not standard for whichever version of Perl your TS ships with (you did not mention your platform, version, etc.), but there IS a way around this...

Using your "other" version of Perl, you can launch a callout where you select, input, whatever your form variable. For instance, mine was a drop-down list... so, as a quick workaround, I used a callout in order to query the info.

Dave

Current Environment(s):
(1) TS 6.1 SP1 on W2K3
(2) TS 6.1 SP1 on W2K
(3) TS 5.5.2 SP2 on Win2K

Dwayne

When launching a script from a prompt session my perl script works properly to access the database but when invoking the script from the DCT is does not work ?

What do you mean by "from the DCT"? Is this via an <inline>, or a CGI? If it's an <inline>, then you probably don't have the environment variables set that you need.

When running the script from within the prompt window it works if I use another perl interpreter , not the one provided with TeamSite 6.1 for Solaris.

It sounds like you might be using a perl module that's not part of the stock TeamSite install, or you're using perl features not compatible with the version of perl that ships with TS. What sort of error messages are you seeing?

Do you have some suggestions about ? we will enter into production this weekend and we are stopped.

Forgive me for saying this, but this sounds like a pretty major error to be encountering this close to a production launch. If I were you're management, I'd say that you were not ready for launch.

--

Current project: TS 5.5.2/6.1 W2K

iwovGraduate

but when invoking the script from the DCT is does not work

How are you invoking the script ? Is it a cgi-callout ? FormAPI/callserver ?

When running the script from within the prompt window it works if I use another perl interpreter , not the one provided with TeamSite 6.1 for Solaris

Without looking at your script, perl version, OS, libs used, etc. its hard to say. Its most likely due to missing perl modules. If you post some more information here, maybe somebody can give you a more concrete answer.

mangetak

HI,

I´m working out this problem with Chema.

We have developed a script as he says that acceses Oracle database to fetch values in order to fill a combo of a DCT.

Before doing the <inline...> call on the DCT we tried first to execute the script on command prompt but used to get an error. We finally found out that the problem was on the enviroment variables to acess Oracle. Some users had the enviroment correctly set on their profile and others didn´t. So we decided to set on the global system enviroments so anyone could execute it and access oracle.

Once weI solved the problem and tried that it worked fine on command prompt (using a perl Interpreter, not the one shipped with TS), I set on muy DCT the <inline command as shown:

<item name="efectos_silencio">
<label>Efectos del silencio (Isilbidearen Ondorioak)</label>
<description></description>
<select required="t">
<inline command="/usr/local/bin/perl /opt/iw-home/custom/loadCombos.pl 1 es"/>
</select>
</item>

But when trying to open the DCT, get the same error:

Root cause:
install_driver(Oracle) failed: Can't load '/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle/Oracle.so' for module DBD: Smiley Surprised

racle: ld.so.1: /usr/local/bin/perl5.6.1: fatal: /oracle9/lib/libclntsh.so.9.0: wrong ELF class: ELFCLASS64 at /usr/local/lib/perl5/5.6.1/sun4-solaris/DynaLoader.pm line 206. at (eval 1) line 3 Compilation failed in require at (eval 1) line 3. Perhaps a required shared library or dll isn't installed where expected at /opt/iw-home/custom/loadCombos.pl line 33

Oracle driver is correctly installed (aparently) and command works perfect in command line whtever user exectutes it.
We have no clue on what can be happening. Has anyone seen this before?

We tried to set within our inline call code the enviroment variables as shown below but still does not work:

use DBI;

$ENV{LD_LIBRARY_PATH}='/oracle9/lib:/oracle9/lib32:/lib:/coblib:/oracle9/lib:/oracle9/lib32:/lib:/coblib';
$ENV{NLS_LANG}='AMERICAN_AMERICA.WE8ISO8859P1';
$ENV{ORACLE_BASE}='/oracle9';
$ENV{ORACLE_HOME}='/oracle9';
$ENV{ORA_NLS33}='/oracle9/ocommon/nls/admin/data';
$ENV{OSTYPE}='solaris';
$ENV{ORACLE_SID}='ede1';
$ENV{PATH}='/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/ssh/bin:/oracle9/bin:/usr/ccs/bin:/usr/local/bin:/etc:.:/usr/bin/X11:/bin:/usr/bin:/oracle9/bin:/usr/ccs/bin:/usr/bin:/etc:.:/usr/bin/X11:/bin:/usr/local/bin:/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris/auto/DBD/Oracle:/usr/local/lib/perl5/5.6.1/sun4-solaris';
$ENV{PWD}='/usr/bin';
$ENV{SHELL}='/usr/bin/ksh';

...

my $dbh=DBI->connect($cadena,$usuario,$password) or print("Error en la conexion a la BBDD");

...

Any idea on why is this happening?

Thanks again in advance

Dwayne

I'd suggest putting the setting of the ENV values inside of a BEGIN block, perhaps even before the use DBI; line, just to make sure things are initialized properly

--

Current project: TS 5.5.2/6.1 W2K

mangetak

Hi,

We have already tried so but get the same error. I

thanks again

mangetak

I´m was just wondering around if this could be done in any other way like.

Developing a servlet which would do the database access and build a string like:

<option value"cc" label="rrr">
<option value"cr" label="rrr">
<option value"ce" label="rrr">

Devloping a perl script that makes a remote call to a servlet. Sth like:

# Script loadCombos.pl
use LWP: Smiley Frustrated

imple;
$var = get("http://servlet...");
print "$var";

And then doing the <inline> to the perl like

<item name="efectos_silencio">
<label>Efectos del silencio (Isilbidearen Ondorioak)</label>
<description>Efectos del silencio</description>
<select required="t">
<inline command="/usr/local/bin/perl /opt/iw-home/custom/loadCombos.pl"/>
</select>
</item>

Anyone know if this would work?

mmb

Try running your initial inline command as a shell script that sets the Environment variables, then calls your Perl script.

This way you know that the Env variables are exported and available to the Perl script that is a child process of the shell script

e.g.

#!/bin/ksh

# set and export vars
LD_LIBRARY_PATH='/oracle9/lib:/oracle9/lib32:/lib:/coblib:/oracle9/lib:/oracle9/lib32:/lib:/coblib'; export LD_LIBRARY_PATH
NLS_LANG='AMERICAN_AMERICA.WE8ISO8859P1'; export NLS_LANG
ORACLE_BASE='/oracle9'; export ORACLE_BASE
ORACLE_HOME='/oracle9'; export ORACLE_HOME
ORA_NLS33='/oracle9/ocommon/nls/admin/data'; export ORA_NLS33
OSTYPE='solaris'; export OSTYPE
ORACLE_SID='ede1'; export ORACLE_SID

# now call the Perl script
/usr/local/bin/perl /opt/iw-home/custom/loadCombos.pl 1 es

This should work...

Good luck,
- mark

Adam Stoller

Why use ksh and create an additional process when you can do the exact same thing within the Perl script and avoid the additional process overhead?:#!/usr/local/bin/perl
BEGIN{
# set [and export] vars
$ENV{LD_LIBRARY_PATH} = '/oracle9/lib:/oracle9/lib32:/lib:/coblib:/oracle9/lib:/oracle9/lib32:/lib:/coblib';
$ENV{NLS_LANG} = 'AMERICAN_AMERICA.WE8ISO8859P1';
$ENV{ORACLE_BASE} = '/oracle9';
$ENV{ORACLE_HOME} = '/oracle9';
$ENV{ORA_NLS33} = '/oracle9/ocommon/nls/admin/data';
$ENV{OSTYPE} = 'solaris';
$ENV{ORACLE_SID} = 'ede1';
};
# now proceed with the rest of the Perl script
...

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mmb

The reason I suggested that is because for some reason, the Perl $ENV{} hash does not always seem to export the variables correctly. [At least it hasnt here on our system Smiley Happy

]

I have found this to be the case with most DBI interaction via the TeamSite GUI's.

If that works, then great... this is just a workable alternative.

- mark

Adam Stoller

When you tried it - did you do it within a BEGIN { ... }; block? If not, that would explain why it didn't seem to work.
The BEGIN block should be processed before the 'use' pragmas.
The 'use' pragmas are processed before other code.

So - if you don't have the environment directives within a BEGIN block - they wont be looked at until *after* the inclusion of the DBI / DBD modules and thus it will be "too late".

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

mmb

That explains it! : )

I wasnt using the BEGIN block.

Thanks for that, it makes sense now.

- mark