Microsoft’s omission caused an enormous hue and cry from stalwart ASP developers who wanted to move to the more powerful .NET application framework while retaining access to their beloved ODBC drivers. It also caused a great deal of confusion among newcomers to Visual Studio .NET who tried—and failed—to make the new .NET OLE DB server controls connect to their ODBC DSN’s. Microsoft responded with a new set of data server controls targeted specifically at ODBC connections, which are available for download here.
Unfortunately, there’s a catch. The normal procedure for establishing an OLE DB or Server data connection within Visual Studio .NET goes something like this:
- Drag the desired table or data view onto the web form. Visual Studio creates the appropriate Data Connection and Data Adapter objects.
- Select Generate Dataset from the Data Adapter’s pop-up menu. The resulting wizard guides the user through a Dataset design process, ultimately producing an appropriately formatted XML schema for the dataset.
- Select Configure Adapter from the Data Adapter’s pop-up menu. The resulting wizard guides the developer through generating the appropriate Data Command objects and hooks these to the dataset, generating all the required code behind the scenes.
On attempting the same procedure with the new ODBC server controls, the user quickly finds that the ODBC Data Adapter server control’s pop-up menu does not include the Generate Dataset and Configure Adapter options. In short, Microsoft has provided the requisite data objects, but has left out the logic required to wire these objects into .NET’s new XML-based Dataset standard.
ASP die-hards will wonder why all the fuss… after all, the old ADO recordset object is still available, and it works as well now as it did before. The developers of the new ODBC server controls must have had the same thought. The answer, however, is that in bypassing the new .NET Dataset, a developer cuts himself off from one of the more flexible and innovative articles in the .NET toolbox. Besides, nobody negotiates the very steep .NET learning curve in order to keep doing the same old thing.
Comments