Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles / Languages / C#

How to easily test your ADO.NET connections

4.20/5 (2 votes)
22 Mar 2011CPOL3 min read 41.2K   1.9K  
If you are having trouble connecting to a database using a program that uses an ADO.NET connector, this program is a great way to test it step by step.

Introduction

If you are having trouble connecting to a database using a program that uses an ADO.NET connector (which is pretty much every C# and .NET app), this program is a great way to test it step by step. There is no license for this code - do anything you want with it.

Note: We rarely use this ourselves as we have numerous development tools to accomplish the same thing. Where this is invaluable is sending this to our customers who are not developers and do not have any tools close to hand that can do this.

Opening a Communications Channel

OK, step 1 is finding a connection string that works. For this, connection strings is your best friend. With the connection string, you then:

  1. Select the vendor you are trying to connect to. DB2, MySQL, and/or Oracle will not be listed if their ADO.NET connector is not correctly installed on your system.
  2. Enter the connection string.
  3. Click Connect.
  4. The status at the bottom will either say Connection successful!, or it will give you the error that occurred when trying to connect.

If the connection fails, it is generally due to one of three issues:

  1. You do not have the ADO.NET connector installed on your system.
    1. In the case of Oracle, it can also be that the Oracle client software is not properly installed on your computer.
  2. You do not have rights to access that database.
  3. The database is not accepting connections. This can be due to both a firewall as well as the database itself.

Retrieving the Metadata

This part makes use of The Kailua Project - the forgotten methods in the ADO.NET API. This is Open Source, and kailua.dll is included in the above downloads.

  1. Under "List Tables", select which mode (User Owned has meaning only with Oracle).
  2. Click Make It So (yes, I was in a Star Trek frame of mind when creating the program).
  3. The table to the right should list all tables, Views, and Stored Procedures.

If you are not getting the metadata, it is usually because:

  1. Your login does not have rights to retrieve metadata (this restriction usually only occurs with DB2 and Oracle). If you think this is the problem, go to "Retrieving Data" below and try a Select. If the Select succeeds and metadata fails, then it is a restriction on your credentials.
  2. Your login does not have rights to access that database.

Retrieving Data

Finally comes pulling data from the database. To run a select:

  1. Click the Select tab.
  2. Enter your Select below "Enter Select".
  3. Click Engage.
  4. You will see the results in the table below the Select.

If this does not work, read the message in the error box at the bottom. Problems here fall in two categories:

  1. Your Select is not valid. In that case, read the documentation on the Select syntax for your vendor.
  2. Your Select is not allowed. This comes back to your credentials again.

Resources

No Code Listed

I didn't show the code in this article because it is, in my opinion, uninteresting. This is a useful tool (it has helped us a lot), but the value is in using the tool, not the code itself.

Now, the code in the Kailua Project is very interesting (or more to the point, the Selects in it are). And I will write articles about that in the future and post a link here when I do.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)