Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.12.2

Bug #700 Feature Request: Oracle should allow a "normal" DSN for a non-TNS connection
Submitted: 2004-02-06 21:35 UTC
From: justinpatrin Assigned: danielc
Status: Wont fix Package: DB
PHP Version: 4.3.3 OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2004-02-06 21:35 UTC] justinpatrin
Description: ------------ When you connect to an Oracle DB which does not have a TNSName set up for it, you have to send a massive (and very Oracle specific) DSN as such: $dsn = 'oci8://user:pass@(DESCRIPTION= (ADDRESS_LIST= (ADDRESS= (COMMUNITY = tcp_comm.world) (PROTOCOL = TCP) (Host = 11.11.11.11) (Port = 1521) ) ) (CONNECT_DATA = (SID = database) (GLOBAL_NAME = database.world) ) )/database'; That's real nasty. I propose an altered oci8.php connection which creates this kind of connection for the user. My diff is below: Index: DB/oci8.php =================================================================== RCS file: /repository/pear/DB/DB/oci8.php,v retrieving revision 1.43 diff -u -r1.43 oci8.php --- DB/oci8.php 22 Jan 2004 15:13:01 -0000 1.43 +++ DB/oci8.php 22 Jan 2004 18:52:04 -0000 @@ -97,7 +97,22 @@ $this->dsn = $dsninfo; $user = $dsninfo['username']; $pw = $dsninfo['password']; - $hostspec = $dsninfo['hostspec']; + if($dsninfo['hostspec'] || $dsninfo['database'] || $dsninfo['port']) { + $hostspec = '(DESCRIPTION= + (ADDRESS_LIST= + (ADDRESS= + (COMMUNITY = tcp_comm.world) + (PROTOCOL = TCP) + (Host = '.$dsninfo['hostspec'].') + (Port = '.($dsninfo['port'] ? $dsninfo['port'] : '1521').') + ) + ) + (CONNECT_DATA = + (SID = '.$dsninfo['database'].') + (GLOBAL_NAME = '.$dsninfo['database'].'.world) + ) +)'; + } $connect_function = $persistent ? 'OCIPLogon' : 'OCILogon';

Comments

 [2004-02-06 21:36 UTC] justinpatrin
For my original discussion of this, see: http://pear.php.net/bugs/bug.php?id=613
 [2004-02-23 17:41 UTC] bibi at free dot fr
007
 [2004-04-07 21:47 UTC] justinpatrin
Is this going to be tacked at some point? I keep having to patch my copy every time another release happens.
 [2004-04-07 22:17 UTC] danielc
This is a nice new feature. But it's a new feature. I'm holding off on new features until I have time to implement them all in a proper fashion.
 [2004-04-07 22:55 UTC] justinpatrin
Heh, forgot about that. Thanks for responding.
 [2004-04-12 18:29 UTC] dave at mausner dot us
oracle TNS details are very site and version specific. for example, not every TNS connection is a member of the TCP community. what if your connection is by named pipe, SPX, or IPC?? the "community" syntax is largely obsolete, as are SID names, which are replaced by service-names. also, nothing prevents you from creating your own TNSNAMES file on your workstation (or whatever), or adding to the names you already have there. altho your suggested modification to db/oci8 seems general and helpful, it is harmful, because it creates two repositories of TNS connection syntax. php/pear should NOT be one of them: your TNSNAMES file is the correct spot.
 [2004-04-12 18:43 UTC] dave at mausner dot us
i am going to add one more comment for those who are less familiar with oracle. the "normal" connection syntax in oracle utilities is "user/password@service" where "service" refers to a named entry in a TNSNAMES file. this entry equates the name to BOTH a host and a database. another option is to treat "service" as a host name in the DNS, for example, "user/password@server.big.com". in this mode, a particular database only is connected on that host(there are other options not relevant to the thread.) my point is that the TNS service is semantically equivalent to the conventional meaning of hostname, and that oracle does not normally allow you to separate hosts and databases at will. (that's what the TNSNAMES files does for you.) use this info to compare the PEAR::DSN syntax. you can see why oracle users might find the DSN un-conventional.
 [2004-05-03 04:31 UTC] danielc
Dave makes some very compelling points.