Coding Insomnia

Back in the early days of the .NET Framework, I believe it was sometime early 2002, I read this article from MSDN Magazine. It describes how the Data Provider framwork can be extended with custom data providers and it was one of those reads that made me think “Wow, this .NET stuff is reeally cool!”.

Ever since I read it I’ve wanted to create my own Data Provider, but I never had any reason to do so. Until yesterday when I got my hands on a prototype for a service that we (propably) will use to connect to the legacy HP NonStop server here at MyTravel.

The prototype service was currently implemented as a single method that took three parameters; the name of the “stored procedure”*, a separator character, and a list of parameters separated by that separator character. The method calls the server and the server responds with some information about the response (number of rows, column names etc) and long string with the result set (separated by tabs and line-breaks). This is then translated into a DataSet which is returned by the service.

While the current design was certainly effective, it didn’t really abstract the database as much as I wanted it to. I thought it would be neat if we could access the NonStop server in exactly the same way as we access our SQL Server. And so I remembered the article above. Since most of the ground was already laid (i.e. how to actually communicate with the server etc.) the process was really easy! It took me about 5-6 hours of programming, and at the end of the day I had a brand new set of classes – among them a DataConnection, a DataCommand, and a DataAdapter. And it works brilliantly!

* They’re not really stored procedures, they are Cobol programs that act more or less like stored procedures.