Set your TNS_ADMIN director to a single place with valid TNSNames and SQLNET.ora files or, You could always hardcode the connect descriptor in the link thus removing TNS as an issue. This gets confusing late at night if not noted primarily because altering the TNS has no effect on hard coded links. :-) Syntax: create public database link TNSBYPASS connect to system identified by manager42 using '(DESCRIPTION=(ADDRESS=(HOST=YOURMACHINE.COM)(PROTOCOL=TCP)(PORT=1521))(CONN ECT_DATA=(SERVICE_NAME=YOURSERVICE.NAME.COM)))' Obviously there are security issues with this approach as well. Also I've run 220.127.116.11, 18.104.22.168, 22.214.171.124, 10.1.0.4, 10.2.0.2 and 10.2.0.3 listeners simultaneously on the same machine. It's not fun, but it was for testing various issues between systems. Main issue we had was with auto registration and crashing listeners when 9 and 10 local_listeners were not set and 126.96.36.199 listener was defaulted to 1521. -Ted _____ From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of David Sharples Sent: Monday, August 13, 2007 2:21 PM To: mccdba1@xxxxxxxxx Cc: Niall Litchfield; oracle-l@xxxxxxxxxxxxx Subject: Re: dblink problem on two verion of ORACLE DB its NOTHING to do with your listener and EVERYTHING to do with your tnsnames setup On 13/08/07, dba1 mcc <mccdba1@xxxxxxxxx> wrote: I knew that is problem, but based on ORACLE say you can Only turn on one listener which is highest version of ORACLE.