Shawn Wildermuth


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

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

Wilder Minds Training
Vue.js by Example (New Lower Price)
Bootstrap 4 by Example (New Lower Price)
Intro to Font Awesome 5 (Free Course)
Pluralsight
Building an API with ASP.NET Core (New Course)
Building a Web App with ASP.NET Core, MVC6, EF Core, Bootstrap and Angular (updated for 2.2)
Less: Getting Started (New)
Using Visual Studio Code for ASP.NET Core Projects
Implementing ASP.NET Web API

My Appearances

No Appearances in 2019
I'm taking a year off of conferences to finish my film, see you in 2020!

Application Name WilderBlog Environment Name Production
Application Ver v4.0.30319 Runtime Framework x86
App Path D:\home\site\wwwroot\ Runtime Version .NET Core 4.6.27514.02
Operating System Microsoft Windows 10.0.14393 Runtime Arch X86