2 Replies Latest reply: Jan 14, 2013 6:38 AM by Paul M. RSS

    tnsnames and ezconnect advantages/disadvantages

    GaryKyle
      I was wondering about the status/preferences between these two connection methods. I have always used the TNS login method user/pass@tnsalias. However, a recent app we have been developing uses a framework that won't read from a networked tnsfile. As such, that app is now using the ezconnect method user/pass@host:port/servicename.

      Also, the 11g client install never creates the network\admin directory that 8,9 and 10 always used to create as the default location for a tnsnames file. Is the tnsnames method of connection less favoured these days, or am I reading too much into it?

      What are the advantages/disadvantages of each method, and is one generally preferred over the other?

      My quick thoughts are that while EZConnect isn't dependent on any environment variables/files to look up for connection information, it also doesn't cover all the additional parameters that are available in a tnsnames file. The tnsnames also has the advantage of acting like a centralised connection string - change once and all apps/services that use it will read the new connection details, rather than needing to update each app's EZConnect connection string individually.
        • 1. Re: tnsnames and ezconnect advantages/disadvantages
          Osama_Mustafa
          EZCONNECT eliminates the need for service name lookups in tnsnames.ora files when connecting to an Oracle database across a TCP/IP network
          CONNECT username/password@[//]host[:port][/service_name]
          refer to
          http://www.orafaq.com/wiki/EZCONNECT

          also as examples :
          http://nuijten.blogspot.com/2010/07/connecting-without-tnsnames.html
          • 2. Re: tnsnames and ezconnect advantages/disadvantages
            Paul M.
            My quick thoughts are that while EZConnect isn't dependent on any environment variables/files to look up for connection information, it also doesn't cover all the additional parameters that are available in a tnsnames file. The tnsnames also has the advantage of acting like a centralised connection string - change once and all apps/services that use it will read the new connection details, rather than needing to update each app's EZConnect connection string individually.
            Agreed. Within the documentation you can also read :

            Easy Connect naming is not suitable for large or complex environments with advanced features, such as connection pooling, external procedure calls, or Heterogeneous Services, that require additional connect information. In these cases, another naming method is recommended.


            We normally use the Easy Connect naming method for "simple" connections, but we discourage it within applications, where tnsnames guarantees a better control.