Shawn Wildermuth


My Rants and Raves about technology, programming, everything else...

XmlDataDocument is Cool

For those who do not know yet, the XML integration with the DataSet is very powerful. Most of the integration is about filling and getting XML from your DataSet. But the XmlDataDocument is really cool. Simply by assigning the DataSet to the XmlDataDocument, you can work with the DataSet data either relationally (through the DataSet) or hierarchically (through the XmlDocument). So, next time you need to transform the DataSet data or just run an XPath query, assign your DataSet to an XmlDataDocument and watch the magic begin...

Firehose your RecordSets

Too many times when I am asked to look at old ADO code, the recordsets are created with a slower cursor than they actually need. This especially prevalent in ASP code. In most every piece of ASP code, the job of the page is to report existing data. In that case you should always us a adOpenForwardOnly cursor. Remember, if you are only reading the data, the other cursor types are using extra database resources and will cause extra round trips to the database. If you are using other cursors just to enable being able to go backwards in the recordset, it is almost always better to use the adOpenForwardOnly cursor and cache the data locally to allow for reverse transversal.

ADO's Parameters.Refresh() is evil

Am I the only that abhors this dreadful API? I understand the usefulness of using Parameters.Refresh() during development. The problem lies in the fact that is it just too easy to leave the code in place. Including an extra network round-trip in every call to this call is simply a waste of time. Now I know that you are an intelligent programmer that never wouldn never leave that code in place, I am talking about all the other programmers that would. Most databases (ignoring Access) allows you to query the database for the information about parameters. Since the database supports, why does ADO have to? I don't think it does.

DataSets are IMDB, Almost

Anyone else remember the promised "In-Memory Database" (IMDB) that was to be part of COM+ some years back? Well, Microsoft has finally delivered a first version of it in ADO.NET's DataSet class.

For those who haven't take a look at ADO.NET yet, don't make the mistake of assuming the DataSet is a replacement of the Recordset from ADO. DataSets contain one or more tables. Tables can be setup with relationships, keys, constraints, etc. Though a real SQL engine does not exist (yet), DataSets do allow you to re-create some of your databases in memory. If you are attempting to scale your database servers, please take a look at this very cool technology!

Let the Database Do Its Job

Ok, this pet peeve is a biggie. Over and over I have seen database schemas that simply defined the table structures and some stored procedures. Most modern database systems support advanced features for maintaining database integrity.

If you are going to go through the trouble to define a database schema, please finish the job. The database will help you do your job if you simply define Relationships, Constraints and Triggers. There are good tools for helping you do this. I really like ERwin or Visio for designing databases.

Remember That Those Connections are Precious

The most common error I see in badly scalable database code is reckless use of the connection object. For all multi-user database programming (which accounts for most of the work these days), database connections are a limited resource. Don't let it be your code that is hanging on to his connection way after you are finished with it. I am *not* saying that all work can be done disconnected. I am simply asking you to keep in mind that Connections are precious things. Try to do these two things:

Shawn
Shawn Wildermuth
Author, Teacher, and Coach


My Courses

pluralsight
Using Visual Studio Code for ASP.NET Core Projects (new)
Implementing and Securing an API with ASP.NET Core (new)
Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS
Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)
Best Practices in ASP.NET: Entities, Validation, and View Models
Webstorm Fundamentals
Front-End Web Development Quick Start
Lessons from Real World .NET Code Reviews
Node.js for .NET Developers
Large Scale JavaScript

My Appearances

Birmingham .NET Users Group
Birmingham, AL - Jul 18, 2017
What's New in ASP.NET Core 2.0

Scenic City Summit
Chatanooga, TN - Jul 28, 2017
Introducing ASP.NET Core

Kansas City Developers Conference
Kansas City, MO - Aug 2-4, 2017
Developing ASP.NET Core in VS Code

PubConf - Kansas City
Kansas City, MO - Aug 5, 2017
JavaScript: It Used to Be Bad, Now It's Awful

Pluralsight Live!
Birmingham, AL - Sep 19-21, 2017
I'm just attending, not speaking...but happy to say hi.

TechBash
Poconos, PA - Oct 4-6, 2017


Application Name WilderBlog Environment Name Production
Application Ver 1.1.0.0 Runtime Framework .NETCoreApp,Version=v1.1
App Path D:\home\site\wwwroot Runtime Version .NET Core 4.6.25211.01
Operating System Microsoft Windows 6.2.9200 Runtime Arch X86