Issue with connecting to Oracle with connection string > 128 chars

Topics: Data Access Application Block
Feb 23, 2009 at 10:45 PM
I hope that this question has been answered before, but I have looked through most of the posts and I didn't see any references to this issue.  I need to connect to Oracle, but my database connection string is greater than 128 characters, which creates an error.  Is there a work around to this issue? 
Feb 24, 2009 at 3:44 AM

Found a discussion regarding the issue. please have a look at this and see if you can get something out of it.

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
Feb 24, 2009 at 5:08 AM

Thank you for the response.  I read through the link; unfortunately that doesn't help.  A bit more detail on my end as to the why....  My connection string has several fail-over servers, etc. and the servers are fully qualified  This is one of the reasons why it exceeds the 128 bit length.  Also, I am making a connection from the client machine to the DB - so I really can't configure a lot of items on the client's box - which rules out some of the dns options on the previous post.  The dns approach would likely be fine if running on the web server as it would be quite reasonable to configure a server or two... 

Also, per the suggestion on the tnsnames.ora....  This is the path I had started with...  However, I ran into some very interesting behaviors.  I am using the ClickOnce technology to distribute my application.  What I had found was that the application using the tnsnames file worked fine on my computer.  However, when I deployed to the Client PCs the connection to Oracle threw an error (ora-12539) - tns buffer over or under flow.  Upon further investigation, I could toggle this error based on where I located the application in terms of directory depth.  The ClickOnce places the execuatable into a very deep subdirectory on the clients computer.  However, when I moved the application to a shallow directory (c:\temp\test), the error went away.  I also tried moving my tnsnames.ora file to a shallow directory while my application remained in the deeply nested directory - no go - the same error as noted above.  I tried a few more items such as using the short dos name to the deep directory, etc. but no go.  I Googled the original error without much luck - which is how I ended up here using the enterprise library as a work around - well, until i ran into the 128 character error...

Hopefully this detail helps a bit - I certainly welcome any and all suggestions as I am stumped at the moment. 
Feb 24, 2009 at 6:12 AM
Another workaround that I can think of is for you to have independent connection string, then implement a functionality that will use the next connection string in case the first one fails. This will require you to encapsulate this behavior to a class. However, I'm not sure how this will fit to your current implementation.

One more thing, as you said that putting the tnsnames.ora into a shallow directory will avoid that error, why dont you try putting both tnsnames.ora and the executable to a shallow directory.

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
Feb 24, 2009 at 10:05 PM

Good point about having multiple connection strings...  That is certainly a possibility and is probably a good enough of a work around to get my going again.  Hopefully some future release of the enterprise library will allow for longer connection strings than the 128 chars...

On the 2nd suggestion - when you use ClickOnce from MS, you can't specify the target on the client's machine.
Nov 5, 2012 at 3:17 PM

I know this conversation is old however it helped me solve an ongoing problem and it might help others.  I experienced the same situation as scchadwi when locating my .NET console application connecting to an oracle instance in a deep path directory.   I get  the ora-12539:tns buffer over error message consistently if I place my exe in a directory that is over 110 characters long.  I suspected the limit for the app path and app name is 128 characters.

I was able to overcome this situation simply by executing the exe in a directory with a shorter path.