09 October 2008

Oracle Error: ORA-06401: NETCMN: Invalid Driver Designator

As a BI Developer, I have the fortunate pleasure of working with numerous database engines such as Microsoft SQL Server, Oracle, IBM DB2, etc.

Here is the catch though; I also have the privilege of running into every possible error produced by each and every single one of those database engines. Trust me when I say there are times I wish I can walk into Oracle headquarters and spit on their lead developer but I'll keep dreaming to myself for now.

So, back to the main focus of this post; Here is one of my favorite error messages that Oracle can throw at you:

ORA-06401: NETCMN: Invalid Driver Designator


A quick look in Oracle's manual will tell you that this error represents an error in your connection string, meaning their is probably a typo somewhere. A quick search on Google will also tell you that this might be a result of Oracle incorrectly parsing the tnsnames.ora file in your Oracle home directory.

All this is fine and dandy, but what if the aforementioned causes do not solve your problem, as was my case. The beauty of this error is that it is not specific in explaining what the exact problem is. Is the connection string incorrect? If so, where? Why?

Here is the hidden secret. Different versions of Oracle Client Software or Oracle Run time Tools will treat a connection string differently. Meaning Oracle Client Software 9 expects a connection string that is different than Oracle Client Software 10. This is so even if your connecting to the same version of a remote Oracle database.

Consider this. Client A is running Oracle Database 10g. Client B wants to connect to Client A through your software. Client B has Oracle Run Time tools 9 installed. Client C also wants to connect to Client A through your software. Client C has Oracle Run Time Tools 10 installed. Remember they are both connecting using your software but which is most likely to work?

If your using a connecting string compatible only with Oracle Run Time Tools 10, Client C will be able to connect and Client B will be unable to do so. Notice that this is regardless of the fact that they are both connecting to the same client.

The best solution to this problem is to use a backwards compatible connection string. However that option is not always available. For example, for a recent project I had to connect to a remote Oracle database using PHP. In PHP, I would typically connect like so:

<?php

$PDO = new PDO( 'oci:dbname=//192.1.1.78:1521/Database' , 'username' , 'password' );


?>


Under the hood, PHP transforms the above into a connection string Oracle can understand. The transformation is hard coded into the PDO extension, which means if you run into this error, your out of luck. The only thing you can really do is install the most recent version of the Oracle Run Time Tools on the machine where your software or script is deployed.

I have seen people run into this problem with other programming languages; C#, Java, etc. The problem is the same as PHP and the solution is exactly the same.

No comments:

Post a Comment

Feel free to write any comments or ideas!

Oracle Error: ORA-06401: NETCMN: Invalid Driver Designator

As a BI Developer, I have the fortunate pleasure of working with numerous database engines such as Microsoft SQL Server, Oracle, IBM DB2, etc.

Here is the catch though; I also have the privilege of running into every possible error produced by each and every single one of those database engines. Trust me when I say there are times I wish I can walk into Oracle headquarters and spit on their lead developer but I'll keep dreaming to myself for now.

So, back to the main focus of this post; Here is one of my favorite error messages that Oracle can throw at you:

ORA-06401: NETCMN: Invalid Driver Designator


A quick look in Oracle's manual will tell you that this error represents an error in your connection string, meaning their is probably a typo somewhere. A quick search on Google will also tell you that this might be a result of Oracle incorrectly parsing the tnsnames.ora file in your Oracle home directory.

All this is fine and dandy, but what if the aforementioned causes do not solve your problem, as was my case. The beauty of this error is that it is not specific in explaining what the exact problem is. Is the connection string incorrect? If so, where? Why?

Here is the hidden secret. Different versions of Oracle Client Software or Oracle Run time Tools will treat a connection string differently. Meaning Oracle Client Software 9 expects a connection string that is different than Oracle Client Software 10. This is so even if your connecting to the same version of a remote Oracle database.

Consider this. Client A is running Oracle Database 10g. Client B wants to connect to Client A through your software. Client B has Oracle Run Time tools 9 installed. Client C also wants to connect to Client A through your software. Client C has Oracle Run Time Tools 10 installed. Remember they are both connecting using your software but which is most likely to work?

If your using a connecting string compatible only with Oracle Run Time Tools 10, Client C will be able to connect and Client B will be unable to do so. Notice that this is regardless of the fact that they are both connecting to the same client.

The best solution to this problem is to use a backwards compatible connection string. However that option is not always available. For example, for a recent project I had to connect to a remote Oracle database using PHP. In PHP, I would typically connect like so:

<?php

$PDO = new PDO( 'oci:dbname=//192.1.1.78:1521/Database' , 'username' , 'password' );


?>


Under the hood, PHP transforms the above into a connection string Oracle can understand. The transformation is hard coded into the PDO extension, which means if you run into this error, your out of luck. The only thing you can really do is install the most recent version of the Oracle Run Time Tools on the machine where your software or script is deployed.

I have seen people run into this problem with other programming languages; C#, Java, etc. The problem is the same as PHP and the solution is exactly the same.

0 Comments:

Post a Comment

Feel free to write any comments or ideas!