OK, so I'm not the first, and not even the second to welcome Mark Edington aboard. But I thought that my former roomie would appreciate the well-deserved props. Mark has been a force in the DB area, which is obviously near and dear to my heart. Abstract datasets, MIDAS, ADO, XML, and BDP have Mark's fingerprints all over them - and that's a real good thing. I'm also looking forward to a rousing blog entry on how to use $L properly. One piece of advice though, Mark. Don't take a vacation. It's hard to get back into the swing of blogging after a vacation, oh, say for 10 days in DisneyWorld.

In order to find out all of the columns that have been changed in a DataSet, you need to resort to code similar to the following. I sure liked the way MIDAS/DataSnap handled this better. A simple call to NewValue, and off you go. Another thing to keep in mind, DataRowVersion.Proposed is only valid between BeginEdit()/EndEdit() calls, so you are forced to write code like this instead:

      if (!dataSet1.HasChanges())
        return;

      DataSet ds = dataSet1.GetChanges();
      foreach (DataTable tbl in ds.Tables)
      {
        foreach (DataRow dr in tbl.Rows)
        {
          for (int i=0; i < tbl.Columns.Count; i++)
          {
            if (dr[i, DataRowVersion.Current] != null && !dr[i, DataRowVersion.Current].Equals(dr[i, DataRowVersion.Original]))
              textBox1.AppendText(tbl.TableName + "." + tbl.Columns[i].ColumnName + " changed (" + dr[i, DataRowVersion.Original] + " -> " + dr[i, DataRowVersion.Current] + ")" + Environment.NewLine);
          }
        }
      }

Even though this is a .NET post, the concept absolutely transfers to classic Delphi as well. The other day, I needed to solve a problem in C#. Given a pseudo-code architecture like this:

class Base {}

class Concrete : Base {}

class Normal
{
  public Concrete ConcreteProp { get; set; }
}

and usage like this:

Base prop = new Concrete();
Normal obj = new Normal();
obj.ConcreteProp = prop;

I would receive (rightfully) a compiler error. Now, understand a few points before firing off comments.

• The architecture must remain as-is. The classes above are actually FCL classes which I obviously can't change.
• The usage needs to remain similar to the one shown above. I want to be able to store a reference to any class that descends from Base and use it in Normal.ConcreteProp later on.
• Obviously, I could just throw a typecast in here to make things work, but this is the end-result of the test case. My requirements also dictated usage of Activator.CreateInstance and Reflection. I can't add references and typecasts to things I don't know about, so this must be truly dynamic.

.NET (and Delphi) don't have any concept of dynamic typecasting. So in order to solve the problem, I ended up taking a different approach. By using an extra Activator.CreateInstance to create a new Concrete obejct, I can then use that new object to assign over with no problems. After creating the object, I then copy over all of the base properties to the newly created object. So far, this has worked pretty well. However, it is not without it's downsides. The main drawbacks I see to this approach are:

• I am not using the same object reference I stored, which means more memory usage
• I cannot easily assign all properties from the cached Concrete object to the newly created one. In order to do this fully, I'll have to use Reflection to walk through all of the properties and set them all (if possible). For now, I know which properties absolutely must be assigned, so I just assign those.

Edited to add: OK, so I butchered the problem description in my haste. Mea culpa. I think I just stumbled into one of my own pet peeves. Here's the actual code that doesn't work in case you're interested:

System.Data.Common.DbDataAdapter adapter = sqlDataAdapter1; 
System.Data.SqlClient.SqlCommandBuilder cb = new System.Data.SqlClient.SqlCommandBuilder(); 
cb.DataAdapter = adapter; 

 

This may be old news to some of you, but I just came across a paper titled Simple Application Framework for VCL by DevExpress. DevExpress has some killer third-party products, including the QuantumGrid. They offer support on a variety of platforms and languages, including Delphi, Kylix, ActiveX, and .NET. Their components work very well, are well-designed, and add pizazz to your application. This paper covers some best practices for Delphi application development. However, if you're a .NET guy, they have a version of the paper for .NET, too.

Andreas Hausladen came up with a way to get D8 apps to run under Mono. For more information, check out this file from SourceForge.

A couple of people have asked me to write up some more in-depth material on interfaces. I like that idea, and will do it at some point. Until then, here are a few links that I came across that cover the ins and outs of interfaces.

'Interfaces: Off the Beaten Track' by Malcolm Groves
'Code Reuse Through Interfaces' by Rob Collins
Joanna Carter's articles 'Hairier Parrots' and 'The All Seeing Eye'

If you know of other URLs, comment here and I'll roll them up to this post.

I'm sure everyone uses version control on their projects. Version control is useful even in one-person teams. If you're not using version control, then maybe I just found Pet Peeve #3.

When using version control it is imperative that you actually check code in that at least compiles. If it doesn't compile, that means that there is zero chance that you tested it. Not only does it mess up the whole build process, but if you didn't test the code, you'll most likely end up doing another build to fix the build you just got done releasing. I don't care how busy you are, or what kind of excuse you can come up with, there is NO excuse for checking code in that doesn't compile. This also leads to another blog on unit testing and automated testing, but I'll leave that for another day. Now I have to go back and finish fixing the build....

OK, time to start my list of pet peeves. When you write code that results in a hint or warning, don't treat it as a congratulations message that everything is going well. Instead, take the time out NOW to stop and fix the hint or warning. If you start getting sloppy and letting hints and warnings go, then you will inevitably get burned later on as a result of this. One perfect example of this was a project that had hundreds of hints and warnings accumulate over the years. One day, a hard to reproduce access violation got reported. Since we didn't have a test case, we had to walk through the code by hand. Finally, I noticed that a variable could possibly not be assigned in one code path. I then actually said out loud "That's funny. I would have thought a warning would have been generated." In response, the developer said "Could be. I don't know. I turned off hints and warnings because there were so many of them." We turned them back on, and sure enough, there was the warning that I expected. We fixed the code, the warning went away, and so did the AV. Shortly afterwards, we took the time to clean up all of the hints and warnings. Heaven knows how many more potential bugs we avoided by cleaning those up. Hopefully, you can learn from this mistake by just reading this. It's a lot less painful than the alternative.