system.Data.OracleClient.dll 1.0.5 and TNSNAME longer than 16 char

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

There is a known issue with system.Data.OracleClient.dll 1.0.50000.0 that
came with NET 1.1 framework: It cannot handle TNSNAME entries that are longer
than 16 chars and produce the error below:

ORA-00162: external dbid length 17 is greater than maximum (16)

Is there a work around or bug fix for this problem? Thanks
 
David P said:
There is a known issue with system.Data.OracleClient.dll 1.0.50000.0 that
came with NET 1.1 framework: It cannot handle TNSNAME entries that are
longer
than 16 chars and produce the error below:

ORA-00162: external dbid length 17 is greater than maximum (16)

Is there a work around or bug fix for this problem? Thanks
Click to expand...

The workaround is to edit your tnsnames.ora file and use a shorter alias.

David
 
That will not work for our case because the file is replicated to thousands
of servers around the world and it is impossible to us to go edit all the
ODBC on these servers. 16 characters is not long enough. I think MS should
modify the dll to handle long entries in TNSNAME files.
 
David P said:
That will not work for our case because the file is replicated to
thousands
of servers around the world and it is impossible to us to go edit all the
ODBC on these servers. 16 characters is not long enough. I think MS should
modify the dll to handle long entries in TNSNAME files.
Click to expand...

Well I do too, but don't hold your breath. It should also accept fully
qualified connection descriptors.

If you have this

ORACLE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = somehost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = oracle)
)
)

in your tnsnames.ora, you should be able to use this

(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = somehost)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = oracle)
)
)

as your data source. OCI likes it fine, and it lets you skip the
tnsnames.ora entirely.

Ok, your other workarounds are:

1) use Oracle's data provider (ODP.NET)
or
2) set the TNSADMIN environment variable to point to a different directory
where you keep a modified tnsnames.ora file.

David
 
I believe that this bug has been fixed in everett service pack 1, you may
want to give it a try at least if installing the sp is an option.
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055 This fix
should also be available as a QFE.

--
Angel Saenz-Badillos [MS] Managed Providers
This posting is provided "AS IS", with no warranties, and confers no
rights.Please do not send email directly to this alias.
This alias is for newsgroup purposes only.
I am now blogging about ADO.NET: http://weblogs.asp.net/angelsb/
 
Angel Saenz-Badillos said:
I believe that this bug has been fixed in everett service pack 1, you may
want to give it a try at least if installing the sp is an option.
http://support.microsoft.com/default.aspx?scid=kb;en-us;885055 This fix
should also be available as a QFE.
Click to expand...

That's great. I tested, and there's still a 128 character limit, but this
works:

@"User Id=scott;Password=tiger;Data
Source=""(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=someserver)(PORT
= 1521)))(CONNECT_DATA=(SERVICE_NAME = oracle)))""");

And for the 10g client, the infinitely simpler //host:port/service naming
works:

@"User Id=scott;Password=tiger;Data Source=//someserver:1521/oracle"

David
 
Back
Top