SQL Stored Procedure Wrapper & Typed DataSet Generator for .NET

• Download source file - 44.4 Kb
• Download demo file - 21.9 Kb

What is this?

DBHelper is a small tool that will generate either a source file or a compiled assembly for selected stored procedures on your SQL server. It uses the CodeDom namespace to output the code. Currently it supports C# and VB.NET code generation (and other language support is likely in the future), but the generated assembly is usable from any .NET language. Also included in version 1.5 is the ability to compile a complete assembly that includes a typed DataSet based on your SQL stored procedures output.

Basically, this is an all-in-one tool for wrapping a SQL database. Great for existing databases, and for rapidly changing databases. E.g. changes gets made to stored procedure's parameters or the output of stored procedures. No problem for DBHelper, just a few clicks and you a have all the methods remapped/DataSet regenerated. All you have to do it adjust your corresponding .NET methods.

NOTE: DBNulls are still not supported. I'm still looking for a way. The alternative is to still generate the source file and the XSD file, and change all the method parameters from their strong type to System.Object. That's all! Hopefully there wont be too many!

New information (version 1.5+)

As of version 1.4, the package comes as a tool rather than a library. Please select the SQL provider (no others will work and I have NO plans to support it). If you tick Create, it will create a corresponding method, and CreateStrong will generate an XSD for strongly typed DataSet/Tables.

Also note VS.NET is NO longer required for typed DataSet generation and compilation (overlooked a static method).

Version 1.6 includes plenty code optimization. Also, typed datasets now get created based on return values. The is no more option to select which ones you want. I have tested it successfully on the MASTER database.

Why?

Some people might ask "Why?". The answer is sweet. Take the following for example:

Every time you even want to execute a simple stored procedure you need something like the following:

SqlCommand cmd = new SqlCommand();
cmd.Connection = connection;
cmd.CommandText = "ChangeEmail";
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.Add("@id", SqlDbType.BigInt).Value = id_param;
cmd.Parameters.Add("@oldemail", SqlDbType.VarChar).Value = oldemail_param;
cmd.Parameters.Add("@newemail", SqlDbType.VarChar).Value = newemail_param;
connection.Open();
cmd.ExecuteNonQuery();
connection.Close();

Now that's only 3 parameters, how about some nasty UPDATE procedures with 10+ parameters? That can be a real time waster, especially doing all the type mapping by hand. On the other hand you could always go for DataSets, and let VS.NET do the work. My personal liking is to use DataSets only for SELECT queries and I usually do all the other statements via SqlCommand's as above. The library will generate all the required parameters and present you with a strongly typed wrapper method for the stored procedure.

UPDATE: I have now updated the library to return a DataTable of the output. For example:

public static DataTable ChangeEmail(SqlConnection connection
    DataTable table, long id_param, 
    string oldemail_param, string newemail_param)

The code from the former example is automatically inserted into a class of choice. Now that looks a lot better, and will probably save you countless hours.

How does it work?

These methods are a bit redundant as of version 1.4 as it run as a tool rather than a library. Firstly your database will be queried for stored procedures. After that we get the name and type of the parameters for each procedure. With the help of CodeDom we create a new class to output to a source file or an assembly.

Constructor

• SP(SqlConnection conn, CodeDomProvider cp);

  Just a reference to a predefined SqlConnection. See example for CodeDomProvider usage.

  E.g. SP sp = new SP(myConnection, new CSharpCodeProvider);

Properties

• public SPCollection Names;

  Returns a strongly typed string collection of all the stored procedure names. This allows you to remove the ones you don't need methods for (as in the UI example).

Methods

• public CompilerResults Compile(string ns, string classname, string asmname);

  Compiles to an assembly (asmname) using values from Names property to generate. Returns results (primarily for debugging).

• public CompilerResults Compile(string[] storedprocs, string ns, string classname, string asmname);

  Compiles to an assembly (asmname) with own defined string array of stored procedures to generate. Returns results (primarily for debugging).

• public void CreateFile(string[] storedprocs, string ns, string classname, string filename);

  Same as compiler, but will output source file.

• public void CreateFile(string ns, string classname, string filename);

  Same as compiler, but will output source file.

Notes

I use a very, very simple mapping from SqlDbType to Type and DBNull values are not supported either in this release.

For the test app to work you will need to change the SqlConnection to your linking.

Free plug

Kristopher Johnson - Typed Collection Class Generator for creating all the collections and dictionaries in DBHelper (although the CodeDom code was not looked at).

Conclusion

This was really my first successful use of CodeDom and it seems really powerful, especially if you use it correctly as output to any language should be possible. As usual, bugs, problems, praise, suggestions, gifts can be added below.

UPDATE: I have created support for VB.NET code as well.

Cheers :)