Sushil's WebLog : Provider and Server Enumeration

Enumerating SQL Servers

sushilc — Thu, 14 Oct 2004 18:56:00 GMT

Continuing with the discussion on enumeration, I will go over ways to enumerate active SQL servers on the network in this blog. Pre-Whidbey, to get list of active servers on the network, we could have done Inter-Op calls to server enumeration APIs in OleDb. If we wanted to write only managed code,we could have broad-casted a carefully crafted UDP packet to the network on port 1434 and waited for response from active SQL Servers and then list them.

In Whidbey, there is an API provided to do the server enumeration. It allows to list active servers on the network. Here is the sample code:

using System.Data;

using System.Data.Sql;

using System;

public class Repro

{

public static int Main(string[] args)

{

SqlDataSourceEnumerator sqldatasourceenumerator1 = SqlDataSourceEnumerator.Instance;

DataTable datatable1 = sqldatasourceenumerator1.GetDataSources();

foreach (DataRow row in datatable1.Rows)

{

Console.WriteLine("****************************************");

Console.WriteLine("Server Name:"+row["ServerName"]);

Console.WriteLine("Instance Name:"+row["InstanceName"]);

Console.WriteLine("Is Clustered:"+row["IsClustered"]);

Console.WriteLine("Version:"+row["Version"]);

Console.WriteLine("****************************************");

}

return 1;

}

Output:
****************************************
Server Name:TESTSERVER-D1
Instance Name:
Is Clustered:No
Version:8.00.194
****************************************
****************************************
Server Name:TESTSERVER01
Instance Name:INST2
Is Clustered:No
Version:8.00.194
****************************************
****************************************
Server Name:TESTSERVER3
Instance Name:
Is Clustered:No
Version:8.00.194
****************************************

What did we do here? SqlDataSourceEnumerator has a public static property that returns an instance of SqlDataSourceEnumerator . The GetDataSources() method on the Enumerator returns a datatable that returns list of active Servers on the network. Following information about the server is included in the table:
1.Server Name: Name of the server.
2.Instance Name: Name of the SQL Server instance. If its a default instance then this is DBNull.
3.Is Clustered: returns Yes, if Server is clustered, else No.
4.Version: returns the full version number of the server listed.

Q:Why do we have a static property Instance on SqlDataSourceEnumerator ?
A:The Instance property is a result of the factorization of the class. The base class, DbDataSourceEnumerator, defines the abstract GetDataSources method. This way, all derived enumerators have to implement it. This implies the method has to be instance method and cannot be static. To make it easy to write code we just added a static property on SqlDataSourceEnumerator that gives its instance.

Q:Why are some values for InstanceName, IsClustered and Version DBNull?
A:The Enumeration API that SQL Client Managed Provider calls, first broadcasts the 'special' packet on port 1434 and waits for a timeout. The replies that it receives with-in the timeout contain all the required information to populate the DataTable. In addition to this,the API looks at the Active Directory (AD) to list the other servers that did not reply for the broadcast packet. There is no way to know the values for InstanceName, IsClustered and Version when listed via AD and hence they are DBNull.

Q:Why are all servers on the network not listed in the list?
A:Since we wait for a time-out it is not guaranteed that we return all the active servers on the network. In fact, the list is most likely to give a different list depending on the network I/O, server performance and other time-depending constraints.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

Using Provider Factories

sushilc — Fri, 08 Oct 2004 21:24:00 GMT

There are situation in real world; when you dont want to write code, dependent on just one of the managed provider. This also helps to easily move from using one provider to another if the code design changes in the future. Pre-Whidbey, the only way to do this was to write your own wrapper classes for the providers. In whidbey this can be done usign ProviderFactories. Here is a sample code:

using System.Data.Common;

using System.Data;

using System;

using System.Data.SqlClient;

namespace DataViewer.Repro

{

public class Repro

{

public static int Main(string[] args)

{

string conString = "ConnectionString here";

string cmdText = "CommandText here";

//Select SQL Client factory - Can change to use any provider later

DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.SqlClient");

//Create Connection from the factory

DbConnection cn = factory.CreateConnection();

cn.ConnectionString = conString;

cn.Open();

//Create Command from the factory

DbCommand cmd = factory.CreateCommand();

//Execute a command from the conneciton

cmd.Connection = cn;

cmd.CommandText = cmdText;

DbDataReader reader = cmd.ExecuteReader();

while (reader.Read())

{

Console.WriteLine(reader.GetValue(0));

}

return 1;

}

After the provider is selected, there is no reference to any of the managed providers in the above code. The above code infact uses the SqlClient MP. In similar way, you can then use the factories to create Parameter, ConnectionStringBuilder, DataSourceEnumerator, Adapter, CommandBuilder and Permissions classes.

Caution:
1. Generalization might also cause an extra overhead.
2. When writing genralized code, you will not be able to use features that are provider specific. You would have to special case them.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights

Provider Enumeration in Whidbey

sushilc — Thu, 07 Oct 2004 19:07:00 GMT

I have been wanting to post for a long time now, and have finally decided to FIGHT my slackness. I will continue with my views on some of the new features in ADO.Net for Whidbey. I will start with talking about a new feature in Whidbey - Provider Enumeration.

Pre-Whidbey there was no way to know if a particular provider is available on your computer. In addition there was no API from ADO.Net that allowed you to choose a provider at execution time (by some cool looking UI) and then run the Application, written in a provider-independent way with the selected provider. There could be scenarios in which getting this list of providers seamlessly from the API could be useful.

In Whidbey, there is a way to enumerate the providers on the computer. Here is a sample program that does just that:

using System.Data;
using System.Data.Common;
using System;

public class Repro
{
  public static int Main(string[] args)
  {
      DataTable datatable1 = DbProviderFactories.GetFactoryClasses(); // DbProviderFactories
      foreach (DataRow row in datatable1.Rows) {
         Console.WriteLine("Provider Name:"+row["Name"]);
         Console.WriteLine("Provider Description:"+row["Description"]);
         Console.WriteLine("Provider Invariant Name:"+ row["InvariantName"]);
         Console.WriteLine("**************************************************************");
      }
      return 1;
   }
}

Output:Provider Name:Odbc Data Provider
Provider Description:.Net Framework Data Provider for Odbc
Provider Invariant Name:System.Data.Odbc
**************************************************************
Provider Name:OleDb Data Provider
Provider Description:.Net Framework Data Provider for OleDb
Provider Invariant Name:System.Data.OleDb
**************************************************************
Provider Name:OracleClient Data Provider
Provider Description:.Net Framework Data Provider for Oracle
Provider Invariant Name:System.Data.OracleClient
**************************************************************
Provider Name:SqlClient Data Provider
Provider Description:.Net Framework Data Provider for SqlServer
Provider Invariant Name:System.Data.SqlClient
**************************************************************

What did I just do? The DbProviderFactories has a static method GetFactoryClasses that enumerates through all the providers that are on my system and returns it as a DataTable. Then I iterate throw all the rows in the DataTable in the foreach statement and print the output. The returned table has 5 columns with the following Column Names

Name: this has the Name of the provider
Description: describes what the provider does
InVariantName: returns the invariant name of the assembly
AssemblyQualifiedName: a fully qualified assembly name
Supported classes: Gets the value of DbProviderSupportedClasses, which tells the set of of classes (Connection, Command, DataReader, Adapter) that this provider supports.

Q: Where is the information about the provider got from?
A: All this information about the provider is received from the Configuration file. (This could be any of the config file- machine-level, app-level or user-level)

Q: Why doesn't a third party provider does not feature in the list even when the provider is installed on my machine?
A: There is no standard way to know if a 3rd party provider is installed on the system. Since the enumeration shows only the information available in the configuration file, to make it appear in the list the information pertaining to the provider should be mentioned in the config file.

In the next blog, I will post how you can use the Factory classes to build provider independent code.

Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights