Re: DBI and oracle: How can I specify more than one host in connect string?

[roboticus]

Skeeve:

mje has it right, you just can't do it that way. However, you could have multiple connection strings. Try the first one, and if it fails, move on to the next one. Stop when you get one that works. Something like the following (untested and probably dreadful):

use DBI;
my $dbh;
my @DSNs = [
   { DSN='blah1', UID='user1', PWD='password1' },
   { DSN='blah2', UID='user2', PWD='password2' },
];
=DBI->connect("dbi:Oracle:host=host1.my.do.main;sid=MYDB","me","secret
+");

my @DSNs = [
'blah1', 'blah2', 'blah3');
for my $hr (@DSNs) {
   $dbh = DBI->connect($$hr{DSN}, $$hr{UID}, $$hr{PWD});
   last unless defined $dbh;
}

...roboticus

[Skeeve]

Okay :-( Then I'm lost as I'm not allowed to (nor willing to) change all the code we have to cope for this stupid bug I have. I think we "simply" have to find the reasson why per dumps core. After that we can do it the right way.

[mje]

I would tend to agree with roboticus on this one. If you are getting a coredump when using a SID something is wrong and although you only know about one thing being broken right now it may turn out you've got other problems you have not found yet.

However, I'm a little surprised at the comment "not allowed to (nor willing to) change all the code we have to cope for this stupid bug" as a) I find it difficult to see just how much code you'd have to change for a change in connect calling (how many calls to connect can you have scattered around) b) you have not ascertained where the problem is yet and c) the use of "stupid bug" doesn't seem too productive. We don't know where the problem lies; it may be in your perl, DBD::Oracle, OCI, NET8, the way any of them were built or perhaps it is a fixed problem and you are using old versions. Did it ever work on this machine and did you install DBD::Oracle without running the tests or install it after running the tests and some of them failed.

Step back and check sqlplus out with your SID to check that is working then if that works move on to unpacking DBD::Oracle, building it and running the tests - do they pass? If you still have problems the dbi-users mailing list is a good place to start but make sure you post the relevant information like platforms, perl -V, versions of modules etc.

[Skeeve]

a) I find it difficult to see just how much code you'd have to change for a change in connect calling (how many calls to connect can you have scattered around)

It's difficult for me too. In this case it would be one script on 2 machine. But since there are several similar scripts I would have to find out which ones should be changed too. And then those scripts are used on otehr machines to and to keep it consistant I would have to apply the changes to the other n-hundred machines too.

b) you have not ascertained where the problem is yet and

Correct. Except that it fails as soon as DBI::connect is executed.

c) the use of "stupid bug" doesn't seem too productive

not productive, but descriptive ;-)

But to answer your question: It never worked on that machine (Intel Solaris). I just copied over a perl from another intel machine. There it fails too. I didn't "install" nor compile anything. It's work done by others in this big company I work for. I already told them but they have no time yet, fixing the bug.

sqlpls works perfectly on the machine. But I can't compile on the machine as there are no compilers (not allowed).

BTW: Even connecting with a host given, is not working perfectly as the connect itself needs aboz 70 seconds.

Thanks for your tips. I will have to talk to the one who compiled perl.

[roboticus]

Skeeve:

That would be my suggestion. Understanding and fixing errors is usually much more profitable than engineering band-aids.

...roboticus