RE: ORA-12154 - (DBD: login failed)

2016-08-08 Thread Howard, Chris 
And tnsnames.ora under each ORACLE_HOME works good using sqlplus or other 
tools, yes?



From: Mani, Arunkumar (BMS - India GDC) [mailto:arunkumar.m...@hpe.com]
Sent: Monday, August 08, 2016 9:37 AM
To: Howard, Chris; Nelson, Erick; mohammed.must...@wipro.com; dbi-users@perl.org
Subject: RE: ORA-12154 - (DBD: login failed)


I'll probably explain it with a piece of code and output, so everybody can 
explain the problem I face clearly.

If you look at 2 codes, the only change is I modified 8i client with 10g 
client. After that it couldn't resolve the TNS connection string.



Perl code with 8i client - works:



#!/usr/local/bin/perl



#use DBI

#use strict;

use strict;

use lib '/u01/home/oracle/admin/site/lib/perl';

use DBI;

$ENV{ORACLE_HOME} = '/u01/home/oracle/product/8.1.7.4';

$ENV{TNS_ADMIN} = '/home/httpd/cgi-bin/oradba';

my $sid = "ECLD.WORLD";

my $usr = "mania2";

my $pas = "blah";

my $dbh = DBI->connect("dbi:Oracle:tns:$sid", $usr, $pas) or die $DBI::errstr;



Output:



bash-2.03$ ./perl_testing1.pl

DBI->connect(tns:ECLD.WORLD) failed: ORA-01017: invalid username/password; 
logon denied (DBD: login failed) at ./perl_testing1.pl line 14

ORA-01017: invalid username/password; logon denied (DBD: login failed) at 
./perl_testing1.pl line 14.

bash-2.03$



Perl code with 10g client - not working:





#!/usr/local/bin/perl



#use DBI

#use strict;

use strict;

use lib '/u01/home/oracle/admin/site/lib/perl';

use DBI;

$ENV{ORACLE_HOME} = '/u01/home/oracle/product/10.2.0';

$ENV{TNS_ADMIN} = '/home/httpd/cgi-bin/oradba';

my $sid = "ECLD.WORLD";

my $usr = "mania2";

my $pas = "blah";

my $dbh = DBI->connect("dbi:Oracle:tns:$sid", $usr, $pas) or die $DBI::errstr;





Output:



bash-2.03$ ./perl_testing1.pl

DBI->connect(tns:ECLD.WORLD) failed: ORA-12154: TNS:could not resolve the 
connect identifier specified (DBD: login failed) at ./perl_testing1.pl line 14

ORA-12154: TNS:could not resolve the connect identifier specified (DBD: login 
failed) at ./perl_testing1.pl line 14.

bash-2.03$





Arunkumar Mani

ITO Service Delivery Consultant

Database Engineering, BMS Account



arunkumar.m...@hpe.com<mailto:arunkumar.m...@hpe.com>

+91 80 338 59305  Office

+91 74062 71026  Mobile



Bangalore, Karnataka/India

hpe.com









-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org]
Sent: Monday, August 8, 2016 7:55 PM
To: Mani, Arunkumar (BMS - India GDC) 
<arunkumar.m...@hpe.com<mailto:arunkumar.m...@hpe.com>>; Nelson, Erick 
<erick.nel...@hdsupply.com<mailto:erick.nel...@hdsupply.com>>; 
mohammed.must...@wipro.com<mailto:mohammed.must...@wipro.com>; 
dbi-users@perl.org<mailto:dbi-users@perl.org>
Subject: RE: ORA-12154 - (DBD: login failed)







ORACLE_HOME not defined correctly?



(I would test by printing out all ENV from within script)







-Original Message-

From: Mani, Arunkumar (BMS - India GDC) [mailto:arunkumar.m...@hpe.com]

Sent: Monday, August 08, 2016 5:38 AM

To: Nelson, Erick; 
mohammed.must...@wipro.com<mailto:mohammed.must...@wipro.com>; 
dbi-users@perl.org<mailto:dbi-users@perl.org>

Subject: RE: ORA-12154 - (DBD: login failed)



Instead of @, we define the connection string in TWO_TASK, and it 
still looks for tnsnames.ora or sqlnet.ora for resolution and it fails.



Arunkumar Mani

ITO Service Delivery Consultant

Database Engineering, BMS Account



arunkumar.m...@hpe.com<mailto:arunkumar.m...@hpe.com>

+91 80 338 59305  Office

+91 74062 71026  Mobile



Bangalore, Karnataka/India

hpe.com







-Original Message-

From: Nelson, Erick [mailto:erick.nel...@hdsupply.com]

Sent: Monday, August 8, 2016 5:01 PM

To: Mani, Arunkumar (BMS - India GDC) 
<arunkumar.m...@hpe.com<mailto:arunkumar.m...@hpe.com>>; 
mohammed.must...@wipro.com<mailto:mohammed.must...@wipro.com>; 
dbi-users@perl.org<mailto:dbi-users@perl.org>

Subject: Re: ORA-12154 - (DBD: login failed)



Did you try TWO_TASK env var ?

<http://www.orafaq.com/wiki/TWO_TASK[orafaq.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.orafaq.com_wiki_TWO-5FTASK=AwMFAg=J-N4xUQ7Pu4HLlwo2BifHA=7-NQstA5IqogNkXFIxVbHg=TfLVDxjcfuPnX0RcZg_ZNMw7NhNJLEbXfv1L7Ps2EgA=LmP3xCjCbYAJUU34ahUes_MUBhkRqsHFQdRdWsng2ZA=>>

<http://www.orafaq.com/wiki/TWO_TASK[orafaq.com]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.orafaq.com_wiki_TWO-5FTASK=AwMFAg=J-N4xUQ7Pu4HLlwo2BifHA=7-NQstA5IqogNkXFIxVbHg=TfLVDxjcfuPnX0RcZg_ZNMw7NhNJLEbXfv1L7Ps2EgA=LmP3xCjCbYAJUU34ahUes_MUBhkRqsHFQdRdWsng2ZA=>>





Erick Nelson

Cell 858-740-6523

Home 760-930-0461





From: "Mani, Arunkumar (BMS - India GDC)" 
<arunkumar.m...@hpe.com<mailto:arunkumar.m...@hpe.com<mailto:arunkumar.m...@hpe.com%3cmailto:arunkumar.m...@hpe.com>>>

Date: Monday, August 8, 2016 at 1:14 AM

RE: ORA-12154 - (DBD: login failed)

2016-08-08 Thread Howard, Chris 


ORACLE_HOME not defined correctly?

(I would test by printing out all ENV from within script)



-Original Message-
From: Mani, Arunkumar (BMS - India GDC) [mailto:arunkumar.m...@hpe.com] 
Sent: Monday, August 08, 2016 5:38 AM
To: Nelson, Erick; mohammed.must...@wipro.com; dbi-users@perl.org
Subject: RE: ORA-12154 - (DBD: login failed)

Instead of @, we define the connection string in TWO_TASK, and it 
still looks for tnsnames.ora or sqlnet.ora for resolution and it fails.

Arunkumar Mani
ITO Service Delivery Consultant
Database Engineering, BMS Account

arunkumar.m...@hpe.com
+91 80 338 59305  Office
+91 74062 71026  Mobile

Bangalore, Karnataka/India
hpe.com



-Original Message-
From: Nelson, Erick [mailto:erick.nel...@hdsupply.com] 
Sent: Monday, August 8, 2016 5:01 PM
To: Mani, Arunkumar (BMS - India GDC) ; 
mohammed.must...@wipro.com; dbi-users@perl.org
Subject: Re: ORA-12154 - (DBD: login failed)

Did you try TWO_TASK env var ?




Erick Nelson
Cell 858-740-6523
Home 760-930-0461


From: "Mani, Arunkumar (BMS - India GDC)" 
>
Date: Monday, August 8, 2016 at 1:14 AM
To: "mohammed.must...@wipro.com" 
>, 
"dbi-users@perl.org" 
>
Subject: RE: ORA-12154 - (DBD: login failed)

All were done earlier. The problem is perl doesn't recognize my sqlnet.ora or 
tnsnames.ora, though I define TNS_ADMIN correctly in the script.
Note: This was working when we used Oracle 8 client.

Arunkumar Mani
ITO Service Delivery Consultant
Database Engineering, BMS Account

arunkumar.m...@hpe.com
+91 80 338 59305  Office
+91 74062 71026  Mobile

Bangalore, Karnataka/India
hpe.com

[hpesm_pri_grn_pos_email_06]

From: mohammed.must...@wipro.com 
[mailto:mohammed.must...@wipro.com]
Sent: Thursday, August 4, 2016 8:53 PM
To: Mani, Arunkumar (BMS - India GDC) 
>; 
dbi-users@perl.org
Subject: Re: ORA-12154 - (DBD: login failed)




Testing: Manually, try connecting to DB using current .ora file content.





Solution:  update .ora file with right
Ip:
Port:
Sid/service name:




Regards,
Mustafa
+44-7440 56 12 32


From: Mani, Arunkumar (BMS - India GDC) 
>
Sent: Thursday, August 4, 2016 8:41 PM
To: dbi-users@perl.org
Subject: ORA-12154 - (DBD: login failed)


** This mail has been sent from an external source **

Hi,



We have a perl script which is used to connect to all our target databases ( 
close to 1000) and fetch the user related information and inturn compare it 
with our enterprise directory which is used to clear the inactive users 
periodically. This was a very old script and it was using Oracle 8i client. 
Since most of our systems were upgraded to 12c, 8i client is not compatible 
with 12c - so we had to update the perl script to use 10g client instead. After 
we did that, we are not able to connect to any databases and getting below 
errors. The script exclusively sets TNS_ADMIN to point to right sqlnet.ora.



Need your help to fix this.



ORA-12154: TNS:could not resolve the connect identifier specified (DBD: login 
failed)



Perl Version:



bash-2.03$ /usr/local/bin/perl -v



This is perl, version 5.005_03 built for sun4-solaris



Copyright 1987-1999, Larry Wall



Perl may be copied only under the terms of either the Artistic License or the

GNU General Public License, which may be found in the Perl 5.0 source kit.



Complete documentation for Perl, including FAQ lists, should be found on

this system using `man perl' or `perldoc perl'.  If you have access to the

Internet, point your browser at 
http://www.perl.com/,
 the Perl Home Page.



bash-2.03$





Arunkumar Mani
ITO Service Delivery Consultant
Database Engineering, BMS Account

arunkumar.m...@hpe.com
+91 80 338 59305  Office
+91 74062 71026  Mobile

Bangalore, Karnataka/India
hpe.com



[hpesm_pri_grn_pos_email_06]


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this

RE: suppress quoting in prepared sql

2016-04-05 Thread Howard, Chris 
Insert "in" values in a table.
Run the query with a sub-select or join against the table.



-Original Message-
From: Paul DuBois [mailto:p...@snake.net] 
Sent: Tuesday, April 05, 2016 11:37 AM
To: Vaughan, Mark
Cc: Bruce Ferrell; dbi-users@perl.org
Subject: Re: suppress quoting in prepared sql


> On Apr 5, 2016, at 12:29 PM, Vaughan, Mark  wrote:
> 
> This works if the number of elements remains static. You'd have to run the 
> prepare again if the number of elements changes.

Sure. But that's true no matter how you construct your statement to be prepared.

> 
> Mark Vaughan
> Neustar, Inc. / Lead Consulting Services Consultant, Professional Services
> 8532 Concord Center Drive, Englewood, CO 80112, USA
> Office: +1.303.802.1308  Fax: +1.303.802.1350  /  mark.vaug...@neustar.biz
> 
> 
> -Original Message-
> From: Paul DuBois [mailto:p...@snake.net] 
> Sent: Tuesday, April 05, 2016 11:25 AM
> To: Bruce Ferrell 
> Cc: dbi-users@perl.org
> Subject: Re: suppress quoting in prepared sql
> 
> 
>> On Apr 5, 2016, at 11:55 AM, Bruce Ferrell  wrote:
>> 
>> Ick!
>> 
>> ok, I have to dynamically build the IN clause of the prepare as a 
>> static sql statement
> 
> Yep. This is how I do it for a given array of values:
> 
> # Create a string of placeholder characters, with one ? character # per 
> element in an array of values.
> 
> my @values = (1, 2, 3, 4, 5);
> 
> my $str = join (",", ("?") x @values);
> 
> Then interpolate $str into your query string.
> 
>> 
>> On 4/5/16 9:32 AM, Vaughan, Mark wrote:
 From the DBI documentation 
 (https://urldefense.proofpoint.com/v2/url?u=https-3A__metacpan.org_p
 od_DBI-23Placeholders-2Dand-2DBind-2DValues-29-3A=CwIF-g=MOptNlV
 tIETeDALC_lULrw=rwT9R07bCzfhX6apOj8NoPX-TbEkSSLuFkjri49xQ-0=QpMl
 4dk0ZSYHx2vhZSJDCeS1tdTQ9Z8GWCyZqgIjc28=2uZZNLLOkgh5xJfTn_SVli361r
 ZOaGOrDxGPv_yVwd8=
>>> 
>>> Also, placeholders can only represent single scalar values. For example, 
>>> the following statement won't work as expected for more than one value:
>>> 
>>> "SELECT name, age FROM people WHERE name IN (?)"# wrong
>>> "SELECT name, age FROM people WHERE name IN (?,?)"  # two names
>>> 
>>> You may have to prepare the query each time unless you have a fixed number 
>>> of elements in the IN clause.
>>> 
>>> HTH,
>>> Mark Vaughan
>>> Neustar, Inc. / Lead Consulting Services Consultant, Professional 
>>> Services
>>> 8532 Concord Center Drive, Englewood, CO 80112, USA
>>> Office: +1.303.802.1308  Fax: +1.303.802.1350  /  
>>> mark.vaug...@neustar.biz
>>> 
>>> 
>>> -Original Message-
>>> From: Bruce Ferrell [mailto:bferr...@baywinds.org]
>>> Sent: Tuesday, April 05, 2016 10:24 AM
>>> To: dbi-users@perl.org
>>> Subject: suppress quoting in prepared sql
>>> 
>>> I'm generating a sql statement like this:
>>> 
>>> sth  = $mysql_dbh->prepare(
>>> "select sum(column) as columnSum from table where value in ( ? ) and 
>>> row_date between cast( ? as date) and cast( ? as date) ");
>>> 
>>> sth->execute( $ValueIDs ,$week_start_date,$week_end_date);
>>> 
>>> $ValueIDs is a series of unquoted values:
>>> 
>>> 01161,01162,01262,01147,01034,01125,01125,01017,01125,01278,01204,011
>>> 64
>>> 
>>> When observed at the mysql server, the sql appears as follows:
>>> 
>>> select sum(column) as columnSum where value in ( 
>>> '01161,01162,01262,01147,01034,01125,01125,01017,01125,01278,01204,01
>>> 164' ) and row_date between cast( '2016-03-29' as date) and cast( 
>>> '2016-04-05' as date)
>>> 
>>> resulting in no data being returned.
>>> 
>>> When the sql is manually entered as follows:
>>> 
>>> select sum(column) as columnSum where value in ( 
>>> 01161,01162,01262,01147,01034,01125,01125,01017,01125,01278,01204,011
>>> 64 ) and row_date between cast( '2016-03-29' as date) and cast( 
>>> '2016-04-05' as date)
>>> 
>>> The correct values are returned.
>>> 
>>> How can I suppress the quoting for the IN clause?
>>> 
>>> 
>> 
>

RE: help with odd DBI perpare/execute errors

2015-06-03 Thread Howard, Chris 
Can you post a copy of your prepare statement?



-Original Message-
From: William Bulley [mailto:w...@umich.edu] 
Sent: Wednesday, June 03, 2015 7:57 AM
To: Martin J. Evans
Cc: dbi-users@perl.org
Subject: Re: help with odd DBI perpare/execute errors

According to Martin J. Evans boh...@ntlworld.com on Wed, 06/03/15 at 09:48:
 
 Sounds ok but the error is invalid string
 
 ORA-0911
 You tried to execute a SQL statement that included a special character.
 
 http://www.techonthenet.com/oracle/errors/ora00911.php
 lists various causes.

Yep, I've been all over the net looking for this issue.  I am not
doing anything wrong -- the invalid string is the darn ?!!!


DBD::Oracle::db prepare failed: ORA-00911: invalid character
(DBD ERROR: error possibly near * indicator at char 370 in '
select distinct s.ITEMIDNUM,
c.STATUSDES,
s.ADDRESS128BIT,
s.PREFIX_LEN,
s.ENDADDRESS128BIT,
s.CREATED_USER,
to_char(s.CREATED_DATE, '-MM-DD HH24:MI:SS'),
i.ITEMDES,
i.COMMENTS,
s.RESERVEDFOR,
s.AGGREGATE_STATUS,
i.STATUSCD,
i.ITEMNAME
from UMNET_ONLINE.IP6NET s, UMNET_ONLINE.ITEM i, 
UMNET_ONLINE.STATUS_CODE c
where i.PARENTITEMIDNUM = *?
  and i.ITEMIDNUM = s.ITEMIDNUM
  and i.STATUSCD = c.STATUSCD
  and i.ITEMCATCD like 'IPv6'
union
select distinct s.ITEMIDNUM,
c.ITEMRELTYPDES,
s.ADDRESS128BIT,
s.PREFIX_LEN,
s.ENDADDRESS128BIT,
s.CREATED_USER,
...'

You can see the error complaining about the question mark above.
There is a second question mark in the second select statement.

 I'm not sure I'd trust that - doesn't that mean you are
 expecting stdin and stout to be in order.

Yes, and they are.

 If you can easily do it I would stick an eval around it and
 trap it that way. Also, if you trap it you can print the SQL using
 http://search.cpan.org/~timb/DBI-1.633/DBI.pm#Statement
 and the parameters using
 http://search.cpan.org/~timb/DBI-1.633/DBI.pm#ParamValues

I'll have to look into that.  But recall this: I am not getting
to the execute() statement.  The above error is on the prepare()
statment.  This is so very confusing to me...

 I would not bother changing from ? to named - I seriously doubt this is the 
 issue.

And you can see from the above that the question mark is back
in the mix.

 http://search.cpan.org/~pythian/DBD-Oracle-1.74/lib/DBD/Oracle.pm#ora_verbose
 
 Can be set in the connect attributes.

Thanks.  :-)

 If I were you I'd try and simply the original case down as much as
 possible but getting a trace with ora_verbose might help identify the problem.

Okay, I'll try that next.

Regards,

web...

-- 

 /\   ASCII RIBBON  / William Bulley
 \ /   CAMPAIGN AGAINST / 
  XHTML E-MAIL AND / E-MAIL: w...@umich.edu
 / \   LISTSERV POSTINGS  /

72 characters width template -|

RE: help with odd DBI perpare/execute errors

2015-06-03 Thread Howard, Chris 
cat scriptname  | od -bc  | more



-Original Message-
From: Bruce Johnson [mailto:john...@pharmacy.arizona.edu] 
Sent: Wednesday, June 03, 2015 11:13 AM
To: William Bulley
Cc: dbi-users@perl.org
Subject: Re: help with odd DBI perpare/execute errors


 On Jun 3, 2015, at 9:44 AM, William Bulley w...@umich.edu wrote:
 
 Martin thinks the parsing in the dbd_preparse() function within the
 dbdimp.c file (part of DBD::Oracle) has issues so that it cannot deal
 with the second question mark given the preceding single quote(s).
 
 It seems plausible, yet odd, to me, but it isn't my module.  Perhaps
 I have an older version?  I dunno...   :-(

I have numerous constructions like yours in my scripts and they work just fine 
(and have for a very long time, I’m pretty sure prior to 2006 which is when 
1.19 was released, so I don’t believe it’s your DBD::Oracle version )

Double check those single quotes, though, I’ve seen editors that try to sneak 
in ‘smart quotes’ and those’ll bollix you every time.

Here’s a quicky test: 

#!/usr/bin/perl
use strict;

foreach my $i (qw (? '  “ ” ‘ ’ )){
print $i is ascii .(ord $i).\n
}

exit; 

This is what it produces:

dbdev2:~ johnson$ perl test
? is ascii 63
' is ascii 39
 is ascii 34
? is ascii 210
? is ascii 211
? is ascii 212
? is ascii 213

Note the displayed ‘?’’s….this is in my standard OSX terminal, which is a 
VT-100 emulator using UTF-8 as the text encoding.

-- 
Bruce Johnson
University of Arizona
College of Pharmacy
Information Technology Group

Institutions do not have opinions, merely customs

time of prepare ?

2012-02-24 Thread Howard, Chris 
I have a DBD::Oracle script which needs some help.

I have other DBD::Oracle scripts working ok, so I think
my installation is fine.  

This particular script attempts to integrate into a larger
application's job security features.

The application vendor supplied me with some wrapped procedures
and an outline for how to make this work.  And I used
it in the past.  But we recently moved to Oracle 11
and the script no longer works.

The tricky part uses a PL/SQL block to run a stored
procedure which figures out what role should be in play
for this particular user when running this particular job.
It then does a dbms_session.set_role, and away we go.

That all seems to work, as far as I can tell.  But
I am failing on a later prepared select of a table
for which I need that role's permissions.

The prepare statement occurs in the file after the
role setting statement.

My question is:  is there some forward-in-time
action going on which causes the prepare to happen
before my role is properly set?  And if so, how
do I defeat that feature?

Chris

RE: time of prepare - solved

2012-02-24 Thread Howard, Chris 
Found my problem.  
Sorry to bother.

I ran part and pieces from sqlplus and determined that
part of the code to set role had a meaning change
between Oracle 8 and Oracle 9.  We went from 8 to 11
so that explains that.

I believe I have it working again.





-Original Message-
From: Howard, Chris [mailto:howa...@prpa.org] 
Sent: Friday, February 24, 2012 1:14 PM
To: 'dbi-users@perl.org'
Subject: time of prepare ?

I have a DBD::Oracle script which needs some help.

I have other DBD::Oracle scripts working ok, so I think
my installation is fine.  

This particular script attempts to integrate into a larger
application's job security features.

The application vendor supplied me with some wrapped procedures
and an outline for how to make this work.  And I used
it in the past.  But we recently moved to Oracle 11
and the script no longer works.

The tricky part uses a PL/SQL block to run a stored
procedure which figures out what role should be in play
for this particular user when running this particular job.
It then does a dbms_session.set_role, and away we go.

That all seems to work, as far as I can tell.  But
I am failing on a later prepared select of a table
for which I need that role's permissions.

The prepare statement occurs in the file after the
role setting statement.

My question is:  is there some forward-in-time
action going on which causes the prepare to happen
before my role is properly set?  And if so, how
do I defeat that feature?

Chris

Oracle DBI on trusted hpux

2012-02-07 Thread Howard, Chris 
kind DBI users,

In order to get some security features that my users
are asking for, it looks like I will need to 
implement trusted mode on our HP-UX servers.

Will that have any impact on Perl/DBI scripts that
run correctly in our current, untrusted mode environment?

We are using Oracle Wallet to store script credentials.

It seems to me that trusted mode should be ok, but
thought I would check first before bringing the
world crashing down.

external password store with perl DBI and CGI

2010-11-11 Thread Howard, Chris 

I have a perl CGI script that uses DBI, connects to a 10g database
and does some simple stuff.  It works.

I want to use Oracle Wallet so that my script does not have
the text of the username/password wired in.

This is on HP-UX and I am using Apache httpd.

I have modified the Apache configuration to use a new 
OS user when it starts the httpd daemon.
I have configured the new OS user to be able
to use Oracle Wallet.  I have tested that with SQLPlus and
it works.  I also have run the modified CGI script from the command
line as that OS user and it works fine.

But... (you knew it was coming!)  Running the CGI script
through the browser still gives me an invalid login error.

I think there must be some environment difference between
running the script from the command line and running
it as CGI but I can't see anything that looks promising.

questions:
1) am I nuts, is there a better way to do this?
2) any idea what needs adjustment?

Thanks!

Chris Howard

RE: external password store with perl DBI and CGI

2010-11-11 Thread Howard, Chris 
Found!

I needed to define $ENV{'HOME'} in my script prior to the
DBI connect so that the .sqlnet.ora file could be located

Thanks!



 -Original Message-
 From: Howard, Chris [mailto:howa...@prpa.org]
 Sent: Thursday, November 11, 2010 10:15 AM
 To: dbi-users@perl.org
 Subject: external password store with perl DBI and CGI
 
 
 I have a perl CGI script that uses DBI, connects to a 10g database
 and does some simple stuff.  It works.
 
 I want to use Oracle Wallet so that my script does not have
 the text of the username/password wired in.
 
 This is on HP-UX and I am using Apache httpd.
 
 I have modified the Apache configuration to use a new
 OS user when it starts the httpd daemon.
 I have configured the new OS user to be able
 to use Oracle Wallet.  I have tested that with SQLPlus and
 it works.  I also have run the modified CGI script from the command
 line as that OS user and it works fine.
 
 But... (you knew it was coming!)  Running the CGI script
 through the browser still gives me an invalid login error.
 
 I think there must be some environment difference between
 running the script from the command line and running
 it as CGI but I can't see anything that looks promising.
 
 questions:
 1) am I nuts, is there a better way to do this?
 2) any idea what needs adjustment?
 
 Thanks!
 
 Chris Howard

RE: sql*net message from client hang

2010-07-08 Thread Howard, Chris 
If it always stops at the same place, it makes me think
of a resource problem, something like a quota?

I don't remember of there are select quotas.

Does it do the same if run as sysdba or some other
well-endowed database user?



 -Original Message-
 From: Dan [mailto:dkele...@gmail.com]
 Sent: Thursday, July 08, 2010 10:02 AM
 To: dbi-users@perl.org
 Subject: sql*net message from client hang
 
 Hello,
   I have some code that has been running happily for many years, but
 suddenly started hanging on a simple select query to our Oracle DB.
 The DB
 shows it as an inactive session with SQL*NET message from client, so
 the
 DB thinks it is waiting for the perl script, but the perl script is
 hung
 reading from the DB according to truss.  I boiled it down to a 20 line
 test
 script that prepares a query using DBI and then executes it ~190 times
 for
 different 10k blocks of the table.  It seems to consistently hang on
 the
 97th iteration, and times out after a few hours hung in SQL*NET
 message
 from client. Has anyone ever come across an issue like this? Even
 stranger,
 when I inserted $dbh-{RowCacheSize} = -1; , it seems to complete
and
 never hang... Our hunch is that this is some issue with the network,
 but
 don't have the expertise to pinpoint what would cause this strange
 behaviour
 
 We are running old DBI .67, but i tried the same script with a local
 version
 of the latest and greatest DBI and DBD::Oracle with the same results.
 Here
 is a sample output from setting $dbh-trace(15); :
 
 96 : 1793727
 - execute for DBD::Oracle::st (DBI::st=HASH(0x40ad7c)~0x40ad4c
 '1793727') thr#12d600
bind :p1 == '1793727' (type 0)
rebinding :p1 (not-utf8, ftype 1, csid 0, csform 0, inout 0)
bind :p1 == '1793727' (size 7/8/0, ptype 4, otype 1)
bind :p1 == '1793727' (size 7/7, otype 1, indp 0, at_exec 1)
 

OCIBindByName(3960a0,404734,38f52c,:p1,3,3a8438,7,1,40474c,0,404744,0
 ,0,2)=SUCCESS
 
 OCIBindDynamic(395e34,38f52c,404710,fefec350,404710,fefec644)=SUCCESS
bind :p1 == '1793727' (in, not-utf8, csid 31-0-31, ftype 1,
 csform
 0-0, maxlen 7, maxdata_size 0)
 OCIAttrSet(395e34,OCI_HTYPE_BIND,ffbff290,0,31,38f52c)=SUCCESS
 dbd_st_execute SELECT (out0, lob0)...
in  ':p1' [0,0]: len  7, ind 0
 OCIStmtExecute(38f4b8,3960a0,38f52c,0,0,0,0,0)=SUCCESS
 OCIAttrGet(3960a0,OCI_HTYPE_STMT,ffbff40a,0,10,38f52c)=SUCCESS
 dbd_st_execute SELECT returned (SUCCESS, rpc0, fn4, out0)
 - execute= '0E0' at simple.pl line 18
 97 : 1793738
 - execute for DBD::Oracle::st (DBI::st=HASH(0x40ad7c)~0x40ad4c
 '1793738') thr#12d600
bind :p1 == '1793738' (type 0)
rebinding :p1 (not-utf8, ftype 1, csid 0, csform 0, inout 0)
bind :p1 == '1793738' (size 7/8/0, ptype 4, otype 1)
bind :p1 == '1793738' (size 7/7, otype 1, indp 0, at_exec 1)
 

OCIBindByName(3960a0,404734,38f52c,:p1,3,3a8438,7,1,40474c,0,404744,0
 ,0,2)=SUCCESS
 
 OCIBindDynamic(395e34,38f52c,404710,fefec350,404710,fefec644)=SUCCESS
bind :p1 == '1793738' (in, not-utf8, csid 31-0-31, ftype 1,
 csform
 0-0, maxlen 7, maxdata_size 0)
 OCIAttrSet(395e34,OCI_HTYPE_BIND,ffbff290,0,31,38f52c)=SUCCESS
 dbd_st_execute SELECT (out0, lob0)...
in  ':p1' [0,0]: len  7, ind 0
 ...
 ### HANGS forever here :(
 ...
 
 Any help is much appreciated!
 
 Thanks,
 Dan

RE: Problems with external password store.

2010-04-21 Thread Howard, Chris 
I am rebuilding my DBD installation on server A  (the one
where Oracle Wallet didn't work)

I set my environment for oracle 10g, then did the
install again.

I have wallet working, but every time I run a script I
get two copies of a dld.sl error for libclntsh.sl.10.1

I think I can live with that for awhile and try to 
clean it up on a scheduled maintenance day.  I'll do
a $ORACLE_HOME/bin/genclntsh and see if that helps.

I have to tell you all, I love DBI/DBD and use it a lot.
But the installation has always seemed to be difficult,
and it keeps me from being enthusiastic to throw on the
latest releases.  When I get it working I just leave
it alone.  Not that I don't sympathize with the difficulty
of building an install that works against Oracle, particularly
in the pre-8 days.  And I'm on HP-UX which also has
it's quirks.



 -Original Message-
 From: John Scoles [mailto:sco...@pythian.com]
 Sent: Tuesday, April 20, 2010 8:38 AM
 To: Howard, Chris
 Cc: John Scoles; dbi-users@perl.org
 Subject: Re: Problems with external password store.
 
 
  Yes you can find out with ORA_OCI
 
 
 
 
 
   use DBD::Oracle qw(:ora_types);
 
  print DBD::Oracle::ORA_OCI
 
 
 
  I think will work
 
  Cheers
 
  John
 
 
 
  Only one wallet is involved, and one connection.
 
  The Oracle Client issue might be in play.  I think
  the case where wallet is not working right may
  have been compiled against an Oracle 8 client.
  It is a pretty old installation.
 
  Is there any way to tell which client is in use?
 
 
 
 
  -Original Message-
  From: John Scoles [mailto:byter...@hotmail.com]
  Sent: Tuesday, April 20, 2010 6:51 AM
  To: Howard, Chris; dbi-users@perl.org
  Subject: RE: Problems with external password store.
 
  If you are trying to connect to both at the same time using two
  different wallets I am afraid you are out of luck.
 
  Seems once a SQLNET.ORA file is read it is 'READ' and cannot be
  reloaded so only one wallet can be used at a time.
 
  It will take the first valid one it finds and use that.
 
  Are you using two wallets and are you trying to connect to both at
 the
  same time??
 
  Your DBD::Oracle is rather old but there is no differance in the
way
  1.24 and 1.16 connect using wallet.
 
  That being said your DBD::Oracle might of been compiled against or
 is
  using an older Oracle client.  Do you know which Oracle client you
 are
  using??
 
 
  Cheers
  John Scoles
 
 
 
  Subject: Problems with external password store.
  Date: Mon, 19 Apr 2010 10:42:16 -0600
  From: howa...@prpa.org
  To: dbi-users@perl.org
 
  I have two database servers, there are some differences
  between the way that perl dbd/dbi is installed on these
  machines, but both are running HP-UX and Oracle 10g.
 
  I am trying to use external password store (oracle wallet)
  to change scripts with embedded login information to be
  more secure.
 
  On server B, I configured oracle wallet to use the
  $HOME/.sqlnet.ora file. It work fine with sqlplus
  and with a very simple perl script.
 
  On server A, I configured oracle wallet the same way
  and it works fine with sqlplus, but the same
  simple perl script gives me invalid username/password
  errors.
 
  I have some version differences between the two machines.
 
  Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
  Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
 
  I may be able to get them eventually on exactly parallel versions
  but that will take quite a bit of time and effort.
 
  Any hope for forward progress otherwise?
 
  Chris Howard
 
 
  
 
  Videos that have everyone talking! Now also in HD! MSN.ca Video.
  http://go.microsoft.com/?linkid=9724460

RE: Problems with external password store.

2010-04-21 Thread Howard, Chris 
I wasn't too clear.

The scripts give error message complaints, but they
actually do work.

Chris


 -Original Message-
 From: Howard, Chris [mailto:howa...@prpa.org]
 Sent: Wednesday, April 21, 2010 12:39 PM
 To: John Scoles
 Cc: John Scoles; dbi-users@perl.org
 Subject: RE: Problems with external password store.
 
 I am rebuilding my DBD installation on server A  (the one
 where Oracle Wallet didn't work)
 
 I set my environment for oracle 10g, then did the
 install again.
 
 I have wallet working, but every time I run a script I
 get two copies of a dld.sl error for libclntsh.sl.10.1
 
 I think I can live with that for awhile and try to
 clean it up on a scheduled maintenance day.  I'll do
 a $ORACLE_HOME/bin/genclntsh and see if that helps.
 
 I have to tell you all, I love DBI/DBD and use it a lot.
 But the installation has always seemed to be difficult,
 and it keeps me from being enthusiastic to throw on the
 latest releases.  When I get it working I just leave
 it alone.  Not that I don't sympathize with the difficulty
 of building an install that works against Oracle, particularly
 in the pre-8 days.  And I'm on HP-UX which also has
 it's quirks.
 
 
 
  -Original Message-
  From: John Scoles [mailto:sco...@pythian.com]
  Sent: Tuesday, April 20, 2010 8:38 AM
  To: Howard, Chris
  Cc: John Scoles; dbi-users@perl.org
  Subject: Re: Problems with external password store.
 
  
   Yes you can find out with ORA_OCI
  
  
  
  
  
use DBD::Oracle qw(:ora_types);
  
   print DBD::Oracle::ORA_OCI
  
  
  
   I think will work
  
   Cheers
  
   John
  
  
  
   Only one wallet is involved, and one connection.
  
   The Oracle Client issue might be in play.  I think
   the case where wallet is not working right may
   have been compiled against an Oracle 8 client.
   It is a pretty old installation.
  
   Is there any way to tell which client is in use?
  
  
  
  
   -Original Message-
   From: John Scoles [mailto:byter...@hotmail.com]
   Sent: Tuesday, April 20, 2010 6:51 AM
   To: Howard, Chris; dbi-users@perl.org
   Subject: RE: Problems with external password store.
  
   If you are trying to connect to both at the same time using two
   different wallets I am afraid you are out of luck.
  
   Seems once a SQLNET.ORA file is read it is 'READ' and cannot be
   reloaded so only one wallet can be used at a time.
  
   It will take the first valid one it finds and use that.
  
   Are you using two wallets and are you trying to connect to both
at
  the
   same time??
  
   Your DBD::Oracle is rather old but there is no differance in the
 way
   1.24 and 1.16 connect using wallet.
  
   That being said your DBD::Oracle might of been compiled against
or
  is
   using an older Oracle client.  Do you know which Oracle client
you
  are
   using??
  
  
   Cheers
   John Scoles
  
  
  
   Subject: Problems with external password store.
   Date: Mon, 19 Apr 2010 10:42:16 -0600
   From: howa...@prpa.org
   To: dbi-users@perl.org
  
   I have two database servers, there are some differences
   between the way that perl dbd/dbi is installed on these
   machines, but both are running HP-UX and Oracle 10g.
  
   I am trying to use external password store (oracle wallet)
   to change scripts with embedded login information to be
   more secure.
  
   On server B, I configured oracle wallet to use the
   $HOME/.sqlnet.ora file. It work fine with sqlplus
   and with a very simple perl script.
  
   On server A, I configured oracle wallet the same way
   and it works fine with sqlplus, but the same
   simple perl script gives me invalid username/password
   errors.
  
   I have some version differences between the two machines.
  
   Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
   Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
  
   I may be able to get them eventually on exactly parallel
versions
   but that will take quite a bit of time and effort.
  
   Any hope for forward progress otherwise?
  
   Chris Howard
  
  
   
  
   Videos that have everyone talking! Now also in HD! MSN.ca Video.
   http://go.microsoft.com/?linkid=9724460

RE: Problems with external password store.

2010-04-21 Thread Howard, Chris 
My script attaches to the database then does a query
of sysdate from dual.


Error shl_load failed for: libclntsh.sl.10.1, [errno 2: No such file or
directory]
/usr/lib/dld.sl: Can't open shared library: libclntsh.sl.10.1
/usr/lib/dld.sl: No such file or directory
Error shl_load failed for: libclntsh.sl.10.1, [errno 2: No such file or
directory]
/usr/lib/dld.sl: Can't open shared library: libclntsh.sl.10.1
/usr/lib/dld.sl: No such file or directory
21-APR-2010

As you can see, it complains a lot but actually does perform.
I haven't tried your SHLIB_PATH ideas yet.. will do that.

Chris


 -Original Message-
 From: John Scoles [mailto:sco...@pythian.com]
 Sent: Wednesday, April 21, 2010 12:59 PM
 To: Howard, Chris
 Cc: John Scoles; dbi-users@perl.org
 Subject: Re: Problems with external password store.
 
 Howard, Chris wrote:
 
 Can you send the error message just for fun.
 
 Cheers
 John
  I wasn't too clear.
 
  The scripts give error message complaints, but they
  actually do work.
 
  Chris
 
 
 
  -Original Message-
  From: Howard, Chris [mailto:howa...@prpa.org]
  Sent: Wednesday, April 21, 2010 12:39 PM
  To: John Scoles
  Cc: John Scoles; dbi-users@perl.org
  Subject: RE: Problems with external password store.
 
  I am rebuilding my DBD installation on server A  (the one
  where Oracle Wallet didn't work)
 
  I set my environment for oracle 10g, then did the
  install again.
 
  I have wallet working, but every time I run a script I
  get two copies of a dld.sl error for libclntsh.sl.10.1
 
  I think I can live with that for awhile and try to
  clean it up on a scheduled maintenance day.  I'll do
  a $ORACLE_HOME/bin/genclntsh and see if that helps.
 
  I have to tell you all, I love DBI/DBD and use it a lot.
  But the installation has always seemed to be difficult,
  and it keeps me from being enthusiastic to throw on the
  latest releases.  When I get it working I just leave
  it alone.  Not that I don't sympathize with the difficulty
  of building an install that works against Oracle, particularly
  in the pre-8 days.  And I'm on HP-UX which also has
  it's quirks.
 
 
 
 
  -Original Message-
  From: John Scoles [mailto:sco...@pythian.com]
  Sent: Tuesday, April 20, 2010 8:38 AM
  To: Howard, Chris
  Cc: John Scoles; dbi-users@perl.org
  Subject: Re: Problems with external password store.
 
 
  Yes you can find out with ORA_OCI
 
 
 
 
 
   use DBD::Oracle qw(:ora_types);
 
  print DBD::Oracle::ORA_OCI
 
 
 
  I think will work
 
  Cheers
 
  John
 
 
 
  Only one wallet is involved, and one connection.
 
  The Oracle Client issue might be in play.  I think
  the case where wallet is not working right may
  have been compiled against an Oracle 8 client.
  It is a pretty old installation.
 
  Is there any way to tell which client is in use?
 
 
 
 
 
  -Original Message-
  From: John Scoles [mailto:byter...@hotmail.com]
  Sent: Tuesday, April 20, 2010 6:51 AM
  To: Howard, Chris; dbi-users@perl.org
  Subject: RE: Problems with external password store.
 
  If you are trying to connect to both at the same time using two
  different wallets I am afraid you are out of luck.
 
  Seems once a SQLNET.ORA file is read it is 'READ' and cannot be
  reloaded so only one wallet can be used at a time.
 
  It will take the first valid one it finds and use that.
 
  Are you using two wallets and are you trying to connect to both
 
  at
 
  the
 
  same time??
 
  Your DBD::Oracle is rather old but there is no differance in the
 
  way
 
  1.24 and 1.16 connect using wallet.
 
  That being said your DBD::Oracle might of been compiled against
 
  or
 
  is
 
  using an older Oracle client.  Do you know which Oracle client
 
  you
 
  are
 
  using??
 
 
  Cheers
  John Scoles
 
 
 
 
  Subject: Problems with external password store.
  Date: Mon, 19 Apr 2010 10:42:16 -0600
  From: howa...@prpa.org
  To: dbi-users@perl.org
 
  I have two database servers, there are some differences
  between the way that perl dbd/dbi is installed on these
  machines, but both are running HP-UX and Oracle 10g.
 
  I am trying to use external password store (oracle wallet)
  to change scripts with embedded login information to be
  more secure.
 
  On server B, I configured oracle wallet to use the
  $HOME/.sqlnet.ora file. It work fine with sqlplus
  and with a very simple perl script.
 
  On server A, I configured oracle wallet the same way
  and it works fine with sqlplus, but the same
  simple perl script gives me invalid username/password
  errors.
 
  I have some version differences between the two machines.
 
  Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
  Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
 
  I may be able to get them eventually on exactly parallel
 
  versions
 
  but that will take quite a bit of time and effort.
 
  Any hope for forward progress otherwise?
 
  Chris Howard
 
 
 
  
 
  Videos that have everyone talking! Now also in HD

RE: Problems with external password store.

2010-04-20 Thread Howard, Chris 
Only one wallet is involved, and one connection.

The Oracle Client issue might be in play.  I think
the case where wallet is not working right may
have been compiled against an Oracle 8 client.
It is a pretty old installation.

Is there any way to tell which client is in use?



 -Original Message-
 From: John Scoles [mailto:byter...@hotmail.com]
 Sent: Tuesday, April 20, 2010 6:51 AM
 To: Howard, Chris; dbi-users@perl.org
 Subject: RE: Problems with external password store.
 
 If you are trying to connect to both at the same time using two
 different wallets I am afraid you are out of luck.
 
 Seems once a SQLNET.ORA file is read it is 'READ' and cannot be
 reloaded so only one wallet can be used at a time.
 
 It will take the first valid one it finds and use that.
 
 Are you using two wallets and are you trying to connect to both at the
 same time??
 
 Your DBD::Oracle is rather old but there is no differance in the way
 1.24 and 1.16 connect using wallet.
 
 That being said your DBD::Oracle might of been compiled against or is
 using an older Oracle client.  Do you know which Oracle client you are
 using??
 
 
 Cheers
 John Scoles
 
 
  Subject: Problems with external password store.
  Date: Mon, 19 Apr 2010 10:42:16 -0600
  From: howa...@prpa.org
  To: dbi-users@perl.org
 
  I have two database servers, there are some differences
  between the way that perl dbd/dbi is installed on these
  machines, but both are running HP-UX and Oracle 10g.
 
  I am trying to use external password store (oracle wallet)
  to change scripts with embedded login information to be
  more secure.
 
  On server B, I configured oracle wallet to use the
  $HOME/.sqlnet.ora file. It work fine with sqlplus
  and with a very simple perl script.
 
  On server A, I configured oracle wallet the same way
  and it works fine with sqlplus, but the same
  simple perl script gives me invalid username/password
  errors.
 
  I have some version differences between the two machines.
 
  Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
  Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
 
  I may be able to get them eventually on exactly parallel versions
  but that will take quite a bit of time and effort.
 
  Any hope for forward progress otherwise?
 
  Chris Howard
 
 
 
 
 
 Videos that have everyone talking! Now also in HD! MSN.ca Video.
 http://go.microsoft.com/?linkid=9724460

RE: Problems with external password store.

2010-04-20 Thread Howard, Chris 
As I suspected the one that doesn't work with wallet
is using Oracle 8.1.7.0 client.

I have some preparatory work to do before I can change that,
but I suspect it is the problem.

Chris


 -Original Message-
 From: John Scoles [mailto:sco...@pythian.com]
 Sent: Tuesday, April 20, 2010 8:38 AM
 To: Howard, Chris
 Cc: John Scoles; dbi-users@perl.org
 Subject: Re: Problems with external password store.
 
 
  Yes you can find out with ORA_OCI
 
 
 
 
 
   use DBD::Oracle qw(:ora_types);
 
  print DBD::Oracle::ORA_OCI
 
 
 
  I think will work
 
  Cheers
 
  John
 
 
 
  Only one wallet is involved, and one connection.
 
  The Oracle Client issue might be in play.  I think
  the case where wallet is not working right may
  have been compiled against an Oracle 8 client.
  It is a pretty old installation.
 
  Is there any way to tell which client is in use?
 
 
 
 
  -Original Message-
  From: John Scoles [mailto:byter...@hotmail.com]
  Sent: Tuesday, April 20, 2010 6:51 AM
  To: Howard, Chris; dbi-users@perl.org
  Subject: RE: Problems with external password store.
 
  If you are trying to connect to both at the same time using two
  different wallets I am afraid you are out of luck.
 
  Seems once a SQLNET.ORA file is read it is 'READ' and cannot be
  reloaded so only one wallet can be used at a time.
 
  It will take the first valid one it finds and use that.
 
  Are you using two wallets and are you trying to connect to both at
 the
  same time??
 
  Your DBD::Oracle is rather old but there is no differance in the
way
  1.24 and 1.16 connect using wallet.
 
  That being said your DBD::Oracle might of been compiled against or
 is
  using an older Oracle client.  Do you know which Oracle client you
 are
  using??
 
 
  Cheers
  John Scoles
 
 
 
  Subject: Problems with external password store.
  Date: Mon, 19 Apr 2010 10:42:16 -0600
  From: howa...@prpa.org
  To: dbi-users@perl.org
 
  I have two database servers, there are some differences
  between the way that perl dbd/dbi is installed on these
  machines, but both are running HP-UX and Oracle 10g.
 
  I am trying to use external password store (oracle wallet)
  to change scripts with embedded login information to be
  more secure.
 
  On server B, I configured oracle wallet to use the
  $HOME/.sqlnet.ora file. It work fine with sqlplus
  and with a very simple perl script.
 
  On server A, I configured oracle wallet the same way
  and it works fine with sqlplus, but the same
  simple perl script gives me invalid username/password
  errors.
 
  I have some version differences between the two machines.
 
  Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
  Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
 
  I may be able to get them eventually on exactly parallel versions
  but that will take quite a bit of time and effort.
 
  Any hope for forward progress otherwise?
 
  Chris Howard
 
 
  
 
  Videos that have everyone talking! Now also in HD! MSN.ca Video.
  http://go.microsoft.com/?linkid=9724460

Problems with external password store.

2010-04-19 Thread Howard, Chris 
I have two database servers, there are some differences 
between the way that perl dbd/dbi is installed on these
machines, but both are running HP-UX and Oracle 10g.

I am trying to use external password store (oracle wallet)
to change scripts with embedded login information to be
more secure.

On server B, I configured oracle wallet to use the
$HOME/.sqlnet.ora file.  It work fine with sqlplus
and with a very simple perl script.

On server A, I configured oracle wallet the same way
and it works fine with sqlplus, but the same
simple perl script gives me invalid username/password
errors.

I have some version differences between the two machines.

Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5

I may be able to get them eventually on exactly parallel versions
but that will take quite a bit of time and effort.

Any hope for forward progress otherwise?

Chris Howard

RE: Problems with external password store.

2010-04-19 Thread Howard, Chris 
TNS_ADMIN is not set in either case.

that's an alternative to the local $HOME/.sqlnet.ora file?



 -Original Message-
 From: Michael Broadwater [mailto:mbroad...@yahoo.com]
 Sent: Monday, April 19, 2010 10:57 AM
 To: Howard, Chris; dbi-users@perl.org
 Subject: Re: Problems with external password store.
 
 Howard,
 
 Please confirm that your TNS_ADMIN variable is set to the correct
 location in the perl script.
 
 Thanks
 -Mike
 
 
 
 From: Howard, Chris howa...@prpa.org
 To: dbi-users@perl.org
 Sent: Mon, April 19, 2010 9:42:16 AM
 Subject: Problems with external password store.
 
 I have two database servers, there are some differences
 between the way that perl dbd/dbi is installed on these
 machines, but both are running HP-UX and Oracle 10g.
 
 I am trying to use external password store (oracle wallet)
 to change scripts with embedded login information to be
 more secure.
 
 On server B, I configured oracle wallet to use the
 $HOME/.sqlnet.ora file.  It work fine with sqlplus
 and with a very simple perl script.
 
 On server A, I configured oracle wallet the same way
 and it works fine with sqlplus, but the same
 simple perl script gives me invalid username/password
 errors.
 
 I have some version differences between the two machines.
 
 Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
 Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
 
 I may be able to get them eventually on exactly parallel versions
 but that will take quite a bit of time and effort.
 
 Any hope for forward progress otherwise?
 
 Chris Howard

RE: Problems with external password store.

2010-04-19 Thread Howard, Chris 
Yes.



 -Original Message-
 From: Michael Broadwater [mailto:mbroad...@yahoo.com]
 Sent: Monday, April 19, 2010 11:43 AM
 To: Howard, Chris; dbi-users@perl.org
 Subject: Re: Problems with external password store.
 
 Does the perl script work without using the wallet?
 
 -Mike
 
 
 From: Howard, Chris howa...@prpa.org
 To: Michael Broadwater mbroad...@yahoo.com; dbi-users@perl.org
 Sent: Mon, April 19, 2010 10:04:17 AM
 Subject: RE: Problems with external password store.
 
 TNS_ADMIN is not set in either case.
 
 that's an alternative to the local $HOME/.sqlnet.ora file?
 
 
 
  -Original Message-
  From: Michael Broadwater [mailto:mbroad...@yahoo.com]
  Sent: Monday, April 19, 2010 10:57 AM
  To: Howard, Chris; dbi-users@perl.org
  Subject: Re: Problems with external password store.
 
  Howard,
 
  Please confirm that your TNS_ADMIN variable is set to the correct
  location in the perl script.
 
  Thanks
  -Mike
 
  
 
  From: Howard, Chris howa...@prpa.org
  To: dbi-users@perl.org
  Sent: Mon, April 19, 2010 9:42:16 AM
  Subject: Problems with external password store.
 
  I have two database servers, there are some differences
  between the way that perl dbd/dbi is installed on these
  machines, but both are running HP-UX and Oracle 10g.
 
  I am trying to use external password store (oracle wallet)
  to change scripts with embedded login information to be
  more secure.
 
  On server B, I configured oracle wallet to use the
  $HOME/.sqlnet.ora file.  It work fine with sqlplus
  and with a very simple perl script.
 
  On server A, I configured oracle wallet the same way
  and it works fine with sqlplus, but the same
  simple perl script gives me invalid username/password
  errors.
 
  I have some version differences between the two machines.
 
  Server B is using DBI 1.601, DBD 1.16, Perl 5.8.8
  Server A is using DBI 1.43, DBD 1.16, Perl 5.8.5
 
  I may be able to get them eventually on exactly parallel versions
  but that will take quite a bit of time and effort.
 
  Any hope for forward progress otherwise?
 
  Chris Howard

RE: Troubles on HP-UX with DBD:Oracle

2002-04-18 Thread Howard, Chris 


Rebuilding all current versions under HP-UX 11.0
appears to have solved the problem!



-Original Message-
From: Howard, Chris 
Sent: Wednesday, April 17, 2002 3:38 PM
To: '[EMAIL PROTECTED]'
Subject: Troubles on HP-UX with DBD:Oracle



Hi,

Thanks for your time in looking this over.
I currently have  DBI, DBD:Oracle running
fine talking to my 7.3.4 databases. This is on
an HP-UX 11.0 platform.

But, as everyone knows, 7.3.4 is ancient history and
the move is on toward 8.1.7 (we tend to lag behind the
times).

I installed an 8.1.7 database on another server.
I have a little script that I run that checks to 
see if I can log in to a database.  It's called isup.pl
and it looks like this:


-- isup.pl -
#!/usr/contrib/bin/perl -w

BEGIN 
{
$ENV{ORACLE_HOME} = '/app/oracle/product/7.3.4';
}
use DBI;

print trying ${ARGV[0]}\n;

$dbh = DBI-connect( dbi:Oracle:${ARGV[0]},$ARGV[1], $ARGV[2] );
if ( defined $dbh )
{
print ${ARGV[0]} is active\n;
exit 0;
}
else
{
exit $DBI::err;
}
end of isup.pl ---

As you can see, I still just have 7.3.4 on this machine.
I am able to run sqlplus and talk to the remote 8.1.7 database.

prompt sqlplus user/pass@FL01

SQL*Plus: Release 3.3.4.0.0 - Production on Wed Apr 17 15:31:45 2002

Copyright (c) Oracle Corporation 1979, 1996.  All rights reserved.


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.1 - Production
With the Partitioning option
JServer Release 8.1.7.0.1 - Production

SQL 

Fine!

But when I try to run isup.pl pointed to the remote database I get this:

prompt isup.pl FL01 user pass

trying FL01
** Internal heap ERROR 17112 addr=0x7f765728 *

* Dump of memory around addr 0x7f765728: 
7F765520   7F78EED0 7F78E280 7F789770 D10DB460 D10DB468
7F78C2B0
7F765540 D10DB498 7F78F0D0 7F78C330 D10DB4A0 D10DB4B0 7F78F174 7F776898
D10DB470
7F765560 7F789C70 D10DB478 7F789CE0 D10DB488 7F789D38 D10DB490 7F789D70
7F78F258
7F765580 7F78F34C 7F78F200 D10E9DF8 D10E9E28 7F78F328 7F785EC0 D10F15D0
D10E9F08
7F7655A0 7F78F0EC D10E9F38 D10E9F70 D10E9FA0 7F78EEA0 D10E9E58 7F7866C8
D10E9E98
7F7655C0 D10E9EC8 D10E9EE8 D10E9C78 7F785318 7F77CF50 D10D5A88 D10F2320
D10E9D40
7F7655E0 7F78F0CC D10E9D80 D10E9DC0 D10DA338 7F78EF34 D10E9CA8 D10DB888
D10E9CC0
7F765600 D10E9CF8 D10E2F30 7F78EFF0 7F78F294 D10E9D20 D10DB870 7F77FD20
7F77AD38
7F765620 7F788FC0 7F78F254 7F78F1FC D10DEC68 7F78EF10 7F78F154 D10DB610
7F78F0E8
7F765640 7F789D90 7F78EF90 7F78F428 D10DEC48 7F78C398 7F78D680 7F789F90
7F788418
7F765660 7F78F0C8 D10DA3E8 D10F6B70 7F78EFEC 7F78F290 7F787170 7F77FDE0
7F78F260
7F765680 7F78F548 D10EB130 D10EB150 7F78A050 D10EB1F8 7F78F150 D10EB228
D10DB448
7F7656A0 D10EB258 D10DB450 7F78F0E4 D10EB288 D10DB458 D10EB168 D10EB190
D10EB1B8
7F7656C0 D10EB1D8 7F786050 7F78ED50 7F78F130 D10D9F58 7F78F0C4 7F779068
7F78F29C
7F7656E0 7F78EF68 7F78F25C D10EB2B8 D10EB2D8 7F78F164 7F78EAD0 D10F1578
D10EB398
7F765700 7F78F14C D10EB3C8 D10EB3F0 D10EB420 D10EB2F8 D10EB320 D10EB348
7F78EFE0
7F765720 7F78F2C0 7F78C448 D10EB370 D10DDE88 7F78ED10 7F78E9E8 1740
7F78DD98
7F765740 7F78F12C D10F2338 7F78F0C0 7F789FB8 7F78F298 D10E2E38 7F78E1E0
7F78EFA4
7F765760 7F77FDC8 7F78F148 D10EAFE8 D10EB008 7F785698 7F78F2BC 7F788870
D10EA738
7F765780 7F77F248 D10EA768 D10E2E20 7F785D30 7F77F268 D10D25A8 D10E2E70
D10EA808
7F7657A0 7F78F128 D10EA840 D10E5F90 D10EA878 D10E5F80 7F78F0BC D10EA898
D10EA788
7F7657C0 D10EA7A8 D10EA7C8 D10EA7E8 7F78F284 7F785BA0 D10F7660 7F78F520
7F77FCA8
7F7657E0 D10EB018 7F78F438 D10EB038 D10EB0B0 7F78F144 7F78F168 7F78F480
D10EB0D8
7F765800 D10DB5C8 7F7949D0 D10F7CBC D10F7C8C D10F7D60 D10F7B00 D10F7AF0
D10F7810
7F765820 D10F7868 D10F7750 D10F776C D10F7748 D10F7728 7F78F630 7F78EC08
D10F7720
...  snipped 

and lots of other nasty stuff ending with 
Bus error(coredump)

A 'file core'  says: 
core:   core file from 'isup.pl' - received SIGBUS

Versions:  I am running Perl 5.0 patchlevel 5 subversion 3
This is HP-UX 11.0  Note ___perl was built under 10.20.
but it has been working fine under 11.0.  Rebuilding perl under
HP-UX 11.0 is something I am willing to try, but I'm mystified
as to how that would be the problem.

Oracle 7.3.4 (client side)  and 8.1.7 (server side-- Linux by the
way.)
DBI version I believe is 1.13
DBD:Oracle is 1_03

I've thought about just getting all the newest stuff and starting from
scratch.  But the fact that sqlplus works whereas DBI/DBD does not is
really strange.


--
Chris Howard CIS Database Administrator
Platte River Power Authority (970) 229 5248

Troubles on HP-UX with DBD:Oracle

2002-04-17 Thread Howard, Chris 


Hi,

Thanks for your time in looking this over.
I currently have  DBI, DBD:Oracle running
fine talking to my 7.3.4 databases. This is on
an HP-UX 11.0 platform.

But, as everyone knows, 7.3.4 is ancient history and
the move is on toward 8.1.7 (we tend to lag behind the
times).

I installed an 8.1.7 database on another server.
I have a little script that I run that checks to 
see if I can log in to a database.  It's called isup.pl
and it looks like this:


-- isup.pl -
#!/usr/contrib/bin/perl -w

BEGIN 
{
$ENV{ORACLE_HOME} = '/app/oracle/product/7.3.4';
}
use DBI;

print trying ${ARGV[0]}\n;

$dbh = DBI-connect( dbi:Oracle:${ARGV[0]},$ARGV[1], $ARGV[2] );
if ( defined $dbh )
{
print ${ARGV[0]} is active\n;
exit 0;
}
else
{
exit $DBI::err;
}
end of isup.pl ---

As you can see, I still just have 7.3.4 on this machine.
I am able to run sqlplus and talk to the remote 8.1.7 database.

prompt sqlplus user/pass@FL01

SQL*Plus: Release 3.3.4.0.0 - Production on Wed Apr 17 15:31:45 2002

Copyright (c) Oracle Corporation 1979, 1996.  All rights reserved.


Connected to:
Oracle8i Enterprise Edition Release 8.1.7.0.1 - Production
With the Partitioning option
JServer Release 8.1.7.0.1 - Production

SQL 

Fine!

But when I try to run isup.pl pointed to the remote database I get this:

prompt isup.pl FL01 user pass

trying FL01
** Internal heap ERROR 17112 addr=0x7f765728 *

* Dump of memory around addr 0x7f765728: 
7F765520   7F78EED0 7F78E280 7F789770 D10DB460 D10DB468
7F78C2B0
7F765540 D10DB498 7F78F0D0 7F78C330 D10DB4A0 D10DB4B0 7F78F174 7F776898
D10DB470
7F765560 7F789C70 D10DB478 7F789CE0 D10DB488 7F789D38 D10DB490 7F789D70
7F78F258
7F765580 7F78F34C 7F78F200 D10E9DF8 D10E9E28 7F78F328 7F785EC0 D10F15D0
D10E9F08
7F7655A0 7F78F0EC D10E9F38 D10E9F70 D10E9FA0 7F78EEA0 D10E9E58 7F7866C8
D10E9E98
7F7655C0 D10E9EC8 D10E9EE8 D10E9C78 7F785318 7F77CF50 D10D5A88 D10F2320
D10E9D40
7F7655E0 7F78F0CC D10E9D80 D10E9DC0 D10DA338 7F78EF34 D10E9CA8 D10DB888
D10E9CC0
7F765600 D10E9CF8 D10E2F30 7F78EFF0 7F78F294 D10E9D20 D10DB870 7F77FD20
7F77AD38
7F765620 7F788FC0 7F78F254 7F78F1FC D10DEC68 7F78EF10 7F78F154 D10DB610
7F78F0E8
7F765640 7F789D90 7F78EF90 7F78F428 D10DEC48 7F78C398 7F78D680 7F789F90
7F788418
7F765660 7F78F0C8 D10DA3E8 D10F6B70 7F78EFEC 7F78F290 7F787170 7F77FDE0
7F78F260
7F765680 7F78F548 D10EB130 D10EB150 7F78A050 D10EB1F8 7F78F150 D10EB228
D10DB448
7F7656A0 D10EB258 D10DB450 7F78F0E4 D10EB288 D10DB458 D10EB168 D10EB190
D10EB1B8
7F7656C0 D10EB1D8 7F786050 7F78ED50 7F78F130 D10D9F58 7F78F0C4 7F779068
7F78F29C
7F7656E0 7F78EF68 7F78F25C D10EB2B8 D10EB2D8 7F78F164 7F78EAD0 D10F1578
D10EB398
7F765700 7F78F14C D10EB3C8 D10EB3F0 D10EB420 D10EB2F8 D10EB320 D10EB348
7F78EFE0
7F765720 7F78F2C0 7F78C448 D10EB370 D10DDE88 7F78ED10 7F78E9E8 1740
7F78DD98
7F765740 7F78F12C D10F2338 7F78F0C0 7F789FB8 7F78F298 D10E2E38 7F78E1E0
7F78EFA4
7F765760 7F77FDC8 7F78F148 D10EAFE8 D10EB008 7F785698 7F78F2BC 7F788870
D10EA738
7F765780 7F77F248 D10EA768 D10E2E20 7F785D30 7F77F268 D10D25A8 D10E2E70
D10EA808
7F7657A0 7F78F128 D10EA840 D10E5F90 D10EA878 D10E5F80 7F78F0BC D10EA898
D10EA788
7F7657C0 D10EA7A8 D10EA7C8 D10EA7E8 7F78F284 7F785BA0 D10F7660 7F78F520
7F77FCA8
7F7657E0 D10EB018 7F78F438 D10EB038 D10EB0B0 7F78F144 7F78F168 7F78F480
D10EB0D8
7F765800 D10DB5C8 7F7949D0 D10F7CBC D10F7C8C D10F7D60 D10F7B00 D10F7AF0
D10F7810
7F765820 D10F7868 D10F7750 D10F776C D10F7748 D10F7728 7F78F630 7F78EC08
D10F7720
..  snipped 

and lots of other nasty stuff ending with 
Bus error(coredump)

A 'file core'  says: 
core:   core file from 'isup.pl' - received SIGBUS

Versions:  I am running Perl 5.0 patchlevel 5 subversion 3
This is HP-UX 11.0  Note ___perl was built under 10.20.
but it has been working fine under 11.0.  Rebuilding perl under
HP-UX 11.0 is something I am willing to try, but I'm mystified
as to how that would be the problem.

Oracle 7.3.4 (client side)  and 8.1.7 (server side-- Linux by the
way.)
DBI version I believe is 1.13
DBD:Oracle is 1_03

I've thought about just getting all the newest stuff and starting from
scratch.  But the fact that sqlplus works whereas DBI/DBD does not is
really strange.


--
Chris Howard CIS Database Administrator
Platte River Power Authority (970) 229 5248