ODBC Connection to Oracle from VB

This is probably fairly easy, which makes the problem all the more frustrating. I am attempting to connect to an Oracle RDBMS using the Microsoft for ODBC Driver.

For some reason I am getting the syntax wrong in the connection string; different variation produce misleading error messages such as "TNS could not resolve service name" - which it defintely can using any other application; or "Invalid username/password" etc.

The following are examples of some variations I have tried (Note this is
VBScript for ASP, but that should be irrelevant):

dim myconnection
dim rsTitleList

set myconnection = Server.CreateObject("ADODB.Connection")

myconnection.Open "server=myserv;" & _      "uid=power;pwd=power;database=myserv"
myconnection.Open "Data source=myserver& _ "uid=power;pwd=power"
myconnection.Open "DSN=myserver;" & _ "uid=power;pwd=MANAGER"

And any number of others - there must be something simple I am missing.....

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

adam_tonkinAuthor Commented:
Edited text of question.
Éric MoreauSenior .Net ConsultantCommented:
This is second question today regarding connecting to Oracle databases using ODBC driver!

What I've suggested to the other programmer was to use (in VB) a DataEnvironment object and then set the connection object to the database. Once the connection is working properly, copy the ConnectionString property to your application and delete the DataEnvironment object.
Try this....

It has all the information reqd. to connect to different database using different options.

Hope it helps

ID: Q193332

The information in this article applies to:

Microsoft Data Access Components versions 1.5, 2.0
Microsoft Data Access SDK, versions 2.0, 2.1
Microsoft Open Database Connectivity, versions 1.0, 2.0, 3.0, 3.5, 3.51
Microsoft OLE DB, versions 1.0, 1.1, 1.5, 2.0
ActiveX Data Objects (ADO), versions 1.0, 1.5, 2.0
Remote Data Service for ADO versions 1.0, 1.1, 1.5, 2.0

Mdaccon.exe is a sample that that demonstrates the use of ODBC Driver and OLE DB Provider connection strings. Four separate projects, one each in C++, Visual Basic for Applications, and Java, as well as a C++ OLE DB Consumer Application, demonstrate the wide variety and specific use of connection strings for commonly used drivers and providers. Additional discussion is included on the following topics:

Connection Strings for ODBC and OLE DB.
Connection Strings for ODBC Drivers.
Using a DSN Created in the ODBC Driver Manager to an ODBC Driver.
Using a DSN-Less Connection to an ODBC Driver.
Using a Native OLE DB Provider.
Connection Strings within OLE DB Consumer Applications.

The following file is available for download from the Microsoft Software Library:

 ~ Mdaccon.exe (size: 110938 bytes)

Release Date: 09-29-1998
For more information about downloading files from the Microsoft Software Library, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q119591
   TITLE : How to Obtain Microsoft Support Files from Online Services

The following code was written using ActiveX Data Objects (ADO). However, it could be just as easily used in the Remote Data Service. If you remove the "PROVIDER=...;" syntax, the same connection string can be used in ODBC, MFC ODBC, Data Access Objects (DAO), DAO with ODBCDirect, or Remote Data Objects (RDO).
Within the Mdaccon.exe file, the projects ADOVB, ADOVC, and ADOVJ demonstrate this same sample code in Visual Basic, Visual C++ and Visual J++ respectively. OLEDBCON demonstrates opening the same connections in an OLE DB Consumer Application.

Connection Strings for ODBC and OLE DB
Applications built using ODBC, MFC ODBC, Data Access Objects (DAO), and Remote Data Objects (RDO) can use connection strings to invoke a specific ODBC Driver to return data from an underlying datastore. Applications using OLE DB, ActiveX Data Objects (ADO), and the Remote Data Service (RDS) can use connection strings to invoke a specific OLE DB Provider to return data, or use the OLE DB Provider for ODBC Drivers to invoke a ODBC Driver as well. The syntax for connection strings between ODBC Drivers and OLE DB Providers is similar, but there are differences in syntax depending upon the underlying datastore, (for example, Microsoft Access, Oracle, SQL Server, and so forth).

Mdaccon.exe uses a minimal subset of sample applications to demonstrate connection strings. Three ADO samples (one each in C++, VBA, and Java) demonstrate both ODBC Driver and OLE DB Provider connection strings. The ODBC Driver Connection string used in the ADO sample is identical to what you would use whether using ODBC, MFC ODBC, DAO, RDO, or RDS. The syntax in ADO for an OLE DB Provider is specific to ADO and RDS. Finally, a fourth sample application in C++ demonstrates the use of OLE DB Provider Connection strings for an OLE DB Consumer application.

Connection Strings for ODBC Drivers
ODBC Connection strings typically refer to a Data Source Name (DSN) that is defined in the ODBC Administrator (found in the Control Panel). The ODBC Administrator lets you define one of three types of DSNs:

User DSN: DSNs defined for the currently logged user only!
File DSN: DSNs stored in a file (independent of any given user).
System DSN: DSNs shared by all users and services (on Windows NT).

A DSN is simply a convenient way to store connection information that would otherwise have to be specified in a connection string. However, you can use what is called a DSN-less connection string and explicitly enumerate all of the connection information in your application independent of the ODBC Administrator. The Mdaccon.exe file and the code samples that follow later in this article, demonstrate both DSN (User or System) and DSN-less connection strings.
The syntax for a DSN, System DSN or File DSN follows:


When using a DSN, the driver, server/data source, and database may have already been specified by the ODBC Administrator and do not usually need to be specified in the connection string. You can specify a database parameter in addition to a DSN to connect to a different database.
It is always a good idea to include the database parameter when you use a DSN. This ensures that you connect to the proper database because another user may have changed the default database since you last checked the DSN definition. Syntactically, there is no difference between a DSN and System DSN.

Syntax without a DSN (DSN-less connection) follows:


With Windows NT and Windows 95 operating systems, in the ODBC Administrator's System DSN dialog box, Data Sources and their (ODBC) Drivers are enumerated.
For developers using OLE DB, ADO, or RDS, this connection string syntax is valid, although you may want to add the PROVIDER= clause, as follows, to indicate that you want to go through the OLE DB Provider for ODBC Drivers:


Because the MSDASQL provider is the default OLE DB provider (for ODBC) for ADO, you often see connection strings that omit the provider parameter. It is good practice to include the provider parameter explicitly to avoid confusion.

Using a DSN Created in the ODBC Driver Manager to an ODBC Driver
The following three code lines demonstrate connecting to ODBC DataSources that have been, respectively, created for Microsoft Access, SQL Server and Oracle. The Access DSN is OLE_DB_Nwind_Jet, created by the Data Access Software Development Kit (SDK) for the Nwind.mdb Microsoft Access database. The SQL Server DSN is LocalServer, created by SQL Server when installed on a computer. The Oracle DSN is dseOracleDSN, created in this case manually on a computer running Oracle client utilities.

   ' Access ODBC Driver via DSN
   con1.Open "PROVIDER=MSDASQL;" & _
             "DSN=OLE_DB_NWind_Jet;" & _

   ' Oracle ODBC Driver via DSN
   con1.Open "PROVIDER=MSDASQL;" & _
             "DSN=dseOracle;" & _

   ' SQL Server ODBC Driver via DSN
   con1.Open "PROVIDER=MSDASQL;" & _
             "DSN=LocalServer;DATABASE=pubs;" & _

For non-ADO/RDS/OLEDB Developers, you would remove the PROVIDER=...; syntax and have a connection string that is perfectly valid for ODBC, MFC ODBC, ODBCDirect and RDO developers.
For ADO/RDS Developers, the PROVIDER=MSDASQL; syntax is optional. By default, ADO and RDS use the OLE DB Provider for ODBC. However, it is good practice to specifically enumerate your provider. Also for ADO and RDS Developers, there is an alternate form of syntax for listing the Data Source Name (DSN), User ID (UID) and Password (PWD). This syntax is valid regardless of underlying provider or driver as it is supported by ADO/RDS.

For all three ODBC Drivers, an alternate form of syntax could be used to specify the Data Source, the User ID, and Password, as shown here for the Microsoft Access ODBC Driver:

   Con1.Open "PROVIDER=MSDASQL;" & _
             "DATA SOURCE=OLE_DB_NWind_Jet;" & _
             "USER ID=admin;PASSWORD=;"

The use of "Data Source", "User ID", and "Password" is syntax specific to ADO and is not viable for any application going directly to ODBC, that is, without the OLE DB Provider for ODBC. "Data Source" is equivalent to "DSN", "User ID" to "UID", and "Password" to "PWD", but only for applications building connection strings through ADO and RDS. This syntax is also valid for the DSN-Less and Native Provider discussion that follow.
There is one more OLE DB/ADO/RDS specific clause that could be used, in this case with the SQL Server Connection string. "INITIAL CATALOG=" is functionally equivalent to "DATABASE=". However, this syntax is only supported if the underlying OLE DB Provider supports this syntax. This is shown in the following code example for the Microsoft Access ODBC Driver:

   Con1.Open "PROVIDER=MSDASQL;" & _
             "DATA SOURCE=LocalServer;INITIAL CATALOG=pubs;" & _
             "USER ID=sa;PASSWORD=;"

Using a DSN-Less Connection to an ODBC Driver
In the following example, notice that SQL Server and Oracle both have Server= parameters but Microsoft Access uses DBQ= to specify a database. SQL Server also specifies an initial catalog to open on the server with the DATABASE= clause.

   '  Access ODBC Driver via DSN-Less
   con1.Open "PROVIDER=MSDASQL;" & _
             "DRIVER={Microsoft Access Driver (*.mdb)};" & _
             "DBQ=C:\...\NWind.mdb;" & _

   '  Oracle ODBC Driver
   con1.Open "PROVIDER=MSDASQL;" & _
             "DRIVER={Microsoft ODBC for Oracle};" & _
             "SERVER=MyOracleServer;" & _

   '  SQL Server ODBC Driver
   con1.Open "PROVIDER=MSDASQL;" & _
             "DRIVER={SQL Server};" & _
             "SERVER=MySQLServer;DATABASE=pubs;" & _

As in the DSN examples, the Provider is specifically enumerated even though you could rely upon ADO's use of this particular provider by default.
The significant difference in each of the three connection strings is the DRIVER= syntax. While shared by all three code samples, the content in between the {} corresponds to the exact syntax of the name of an ODBC Driver registered in the ODBC Driver Manager.

The other main difference between each data source is the syntax used to specify the actual database being opened. For Microsoft Access the DBQ clause is used to provide a path to an actual Microsoft Access .mdb file. For SQL Server both the server name as well as the database to access within that server are specified. For Oracle a value that matches the name of a service specified in the SQL Easy Net utility is specified.

Using a Native OLE DB Provider
Note in the following that the Microsoft Access and Oracle OLE DB native providers need a different User ID and Password syntax than that used in any of the other connection strings.

   ' Access Provider
   con1.Open "PROVIDER=Microsoft.Jet.OLEDB.3.51;" & _
             "DATA SOURCE=C:\...\NWind.mdb;" & _
             "USER ID=admin;PASSWORD=;"

   '  Oracle Provider
   con1.Open "PROVIDER=MSDAORA;" & _
             "DATA SOURCE=MyOracleServer;" & _
             "USER ID=demo;PASSWORD=demo;"

   '  SQL Server Provider
   con1.Open "PROVIDER=SQLOLEDB;" & _
             "DATA SOURCE=MySQLServer;DATABASE=pubs;" & _
             "USER ID=sa;PASSWORD=;"

Once again the Provider= clause is used, but this time it refers to the ProgID of native OLE DB providers other than the OLE DB Provider for ODBC Drivers.
For Microsoft Access and Oracle, the ODBC syntax of DSN, UID, and PWD is not supported. However the SQL Server OLE DB Provider does support the use of this otherwise ODBC-specific syntax.

The DATA SOURCE= syntax is identical to the SERVER= and DBQ= syntax you see with DSN-less connection strings.

For both Microsoft Access and Oracle Native OLE DB Providers, the DSN=, UID=, and PWD=, syntax are not supported. However, the SQL Server OLE DB Provider recognizes this otherwise ODBC-Driver specific syntax, as shown in the following example:

    '  SQL Server Provider
    Con1.Open "PROVIDER=SQLOLEDB;" & _
              "DSN=LocalServer;DATABASE=pubs;" & _

Connection Strings Within OLE DB Consumer Applications
The preceding code samples utilized ADO's connection object. However, what about for an OLE DB Consumer application? The equivalent OLE DB code would set the values of provider properties in order to make a connection. Specifically, equivalent OLE DB code for each of the preceding samples would reference one or more of the following OLE DB Properties:

   OLE DB Property               Description

   DBPROP_INIT_DATASOURCE         This property is equivalent to DSN= when
                                  using the OLE DB provider for ODBC to go
                                  to an ODBC Datasource.  Otherwise, it
                                  names either the Server (Oracle, SQL
                                  Server Providers) or database file (Jet
                                  Provider) that is to be opened.

   DBPROP_AUTH_USERID             This property is equivalent to the UID=
                                  ODBC syntax.

   DBPROP_AUTH_PASSWORD           This property is equivalent to the PWD=
                                  ODBC Syntax.

   DBPROP_INIT_CATALOG            This property is equivalent to the
                                  DATABASE= ODBC Syntax.

   DBPROP_INIT_PROVIDERSTRING     This property lets you cheat and pass
                                  your existing ODBC Connection String
                                  to the OLE DB Provider for ODBC.
                                  Otherwise it is useful for provider
                                  specific connection information.

The Mdaccon.exe file contains a project, OLEDBCON, which demonstrates connecting to Microsoft Access, Oracle, and SQL Server through various combinations of these OLE DB Properties. Demonstrated first is the use of the native OLE DB provider for each Datasource, then various permutations going through the OLE DB Provider for ODBC to ODBC Drivers for each Datasource.

Data Access SDK; search on: "Connection String Syntax"; "Properties Table".

Microsoft Developer Network: search on: "Using OLE DB Providers with ADO"

The white paper "OLE DB for the ODBC Programmer" contains a useful discussion for creating an OLE DB Consumer Application that was the basis for the OLE DB sample used with this article. You can download this white paper from the following location:


"The ODBC Programmer's Reference", Chapter 6 "Connecting to a Data Source or Driver", ISBN 1-57231-416-4.
"Setting Connection String Parameters in DAO", white paper, by Joel Gilman. This white paper can be found at the following Web URL:



Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
adam_tonkinAuthor Commented:

Thanks for that... This information will be very helpful.

I actually got it working; the problem was the provider name. As described by your text, the provider name should have been MSDASQL.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.