Month: February 2011

Workaround for NullReferenceException in DBComparer

DBComparer 3.0 is a great tool if you want to synchronize your SQL Server database environments and don’t have hundreds of dollars to spend on Red Gate’s SQL Compare.  It’s simple to use and free.

http://dbcomparer.com/

I used it for a couple of weeks without any problem until one day when I tried to compare with a particular server and it crashed:

DBComparer NullReferenceException

Looking at the error message, we can deduce that the WriteRecentList() function saves the names of the servers you have typed in the recent servers list.  This is sort of like the recent files list found in some applications.

SettingsBase is part of the .NET Framework, and this part of the code is probably used to persist application settings.  A little digging around on the MSDN library reveals this:

Specific user data is stored in a file named user.config, stored under the user’s home directory. If roaming profiles are enabled, two versions of the user configuration file could exist. In such a case, the entries in the roaming version take precedence over duplicated entries in the local user configuration file.

A look in the user.config file confirms our theory that this is where the list of recent servers are stored.  However, DBComparer is only designed to support 10 recent server names (5 on each side of the comparison).  Any more than that and it blows up.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <userSettings>
    <DBCompare.Properties.Settings>
      <setting name="RecentServerName11" serializeAs="String">
        <value>server1</value>
      </setting>
      <setting name="RecentServerName12" serializeAs="String">
        <value>server2</value>
      </setting>
      <setting name="RecentServerName13" serializeAs="String">
        <value>server3</value>
      </setting>
      <setting name="RecentServerName14" serializeAs="String">
        <value>server4</value>
      </setting>
      <setting name="RecentServerName15" serializeAs="String">
        <value>server5</value>
      </setting>
      <setting name="RecentServerName21" serializeAs="String">
        <value>server6</value>
      </setting>
      <setting name="RecentServerName22" serializeAs="String">
        <value>server7</value>
      </setting>
      <setting name="RecentServerName23" serializeAs="String">
        <value>server8</value>
      </setting>
      <setting name="RecentServerName24" serializeAs="String">
         <value>server9</value>
      </setting>
      <setting name="RecentServerName25" serializeAs="String">
        <value>server10</value>
      </setting>
    </DBCompare.Properties.Settings>
  </userSettings>
</configuration>

As a workaround until this bug is fixed, you can delete some or all of the server names in the value tags to make room for more and prevent the error.

Advertisement

Same Markup, Same Browser, Different Results

Here is a simple HTML5 page I created:

<!DOCTYPE html>
<html lang="en">
<head>
 <meta charset="utf-8" />
 <title>Inconsistent Rendering</title>
</head>
<body>
 <span style="height: 1px; overflow: visible; background-color: Green;">
 <h1>This is a test.</h1>
 </span>
</body>
</html>

And here is that page rendered in Internet Explorer 8.  In one case it’s being served on my laptop, and the other on the local intranet.

Test file on localhost

Test file on intranet

The markup, the Web servers, and the browser are all set up 100% the same.  These should be identical, shouldn’t they?  What’s the problem?  The answer is Compatibility View.

Compatibility View is a “feature” of Internet Explorer that causes it to ignore modern Web standards.  That would be fine, except Compatibility View settings vary by zone, and different zones have different defaults.  Also, the Compatibility View button in the address bar isn’t always available, which means there’s no visual indicator as to what mode you’re in, and you can’t change modes for the current page easily.

Compatibility View settings can be accessed in the Tools –> Compatibility View Settings menu, but if you’ve developed a standards compliant intranet site, you need a better fix than simply asking each individual user to reconfigure their browser.  Group Policy is one option, but there is a much simpler solution.  Just add the following meta tag to your pages, and it will force IE 8 to use the !DOCTYPE declaration in the page to determine the rendering mode.

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" />

If you’re experiencing rendering inconsistencies with the same markup being served from different environments, have a look into Compatibility View. It just might be the culprit.