Today I didn't bill for my time. I couldn't. I finally hit the wall on hard drive space; a problem I've been ignoring for way too long.

Don't get me wrong, I'm not completely irresponsible on this front. I do run backup software and keep an up-to-the-hour image of everything that happens on my drive each day. The problem I'm talking about has more to do with the shear volume of digital stuff we keep these days. Mail, pictures, music, documents, code, notes, recipes you name it, seems like everything we do these days is stored digitally and the delima of what to do with it all is catching up with me.

On our last trip to Canada my children averaged 1 GB pictures per week. In and of itself that's not too much data, but what do you do with years of this stuff? I'm putting the temporary solution in place today: 400 GB drives installed in a Windows 2000 machine mirrored as one drive. In theory this should give me roughly 400 GB of storage with a redundant, always up-to-date, backup. However, we lost two drives in one machine last summer due to a power surge. Hmmmm... it's on a UPS now, but... still makes we wonder. So, my plan is to add one more 400 GB external drive via USB 2.0 and back up my storage drive at least once a week. I figure that's the best I can do, at least in my price range.

However, all of this still does not solve the long term problem; it just delays it. Whether it's a year from now or five years from now we are eventually going to run out of space on this 400 GB drive. Then what? Hopefully there will be larger drives at an affordable price, but this all seems somewhat absurd, not to mention volitile.

Thus the delima: how do we cope in a digital world? What are the right solutions? What are the wrong solutions? What do we do with all this digital stuff?

I added a new option to our web.config file today under the appConfig section. There was nothing special about this entry. It used a key / value pair where the key was a string and the value an integer. Again, nothing special. I added a comment above and closed the file.

Next I ran the debugger to test my recent changes. To my surprise I got a message box stating that the Debugger could not attach to the web server.

"Error while trying to run project: Unable to start debugging on the web server. Server side-error occurred on sending debug HTTP request.

Make sure the server is operating correctly. Verify there are no syntax errors in web.config by doing a Debug.Start without Debugging. You may also want to refer to the ASP.NET and ATL Server debugging topic in the online documentation."

(Note to self: read message boxes more carefully the first time in the future.)

Odd, I just debugged this thing a few minutes ago. Unshaken I rebooted my machine and waited; thinking that IIS had just temporarily gotten hung up. After the reboot, however, I got the following error when opening my project in Visual Studio 2003:

"The Web server reported the following error when attempting to create or open the Web project located at the following URL: 'http://localhost'. 'HTTP/1.1 500 Internal Server Error'.

<Sigh> One of those days I see.

I opened up Google and began to search for the solution. However, after poking around a bit I hadn't found anything that cured my problem. <sigh again>

At this point I started considering what changes I had made. What possibly could have effected the opening of a Visual Studio project. Ah hah! The web.config. I had changed the web.config! So, I opened up the file to look for typos. Hmmmm... nothing there. Everything looked fine. I removed my recent additions anyway, just to see if it would help.

It did! The file opened right up without error. Alright! Now to figure out what the problem was.

As it turns out the problem was part of the comment I had made for my recent configuration key. In my comment I had added multiple dashes (-----) as a separator for a example text I had added. As it turns out these dashes seem to have caused the Visual Studio project launcher to croak. Furthermore, they cause the Visual Studio compiler to be unable to function properly.

Example:
<!--
  This is an example of what *NOT* to do in a web.config file.
  
  You should not use multiple dashes like I do below.

  Example:
  --------
  Blah
  Blah

  or it will cause problems
  -->

So, the lesson here is: do not use multiple dashes (-----) in your comments for a web.config (or I'm guessing any .NET config file) or it will cause problems that are VERY difficult to track down.

We write a lot of code around here. As a result we often run into strange things that seem impossible to figure out. However, over the past 18 years, I have come to realize that with very few, if any, exceptions (no pun intended) the cause of even the most complicated errors can be determined.

Yesterday one of those very odd situations arose. We have a large application that is written in VB.NET and C#. When calling one of the the web methods on a web service written in C# I found that I was getting back nothing instead of the large set of data that was expected. Upon investigation I realized that this was only happening when the code was compiled for release and that the error does not occur in debug mode. Although this is odd, it is not complete unbelievable since it is possible that something was put into the debug only portion of the code that should not have been there. However, this time, that was not the case. The same exact code was getting executed in both modes.

The exception that was occurring was: "Invalid attempt to Read when reader is closed." The code block looked something like this:

Hashtable htObjects = new Hashtable();
SqlDataReader sdrObjects = null;

try
{

   sdrObjects = objectRepository.GetObjects(true);

   int intObjectId = 0;
   COurObject theObject = null;

   if (sdrObjects != null)
   {
      while (sdrObjects.Read())
      {
         intObjectId = sdrObjects.GetInt32(1);
         if (intObjectId != 0)
         {
            theObject = new COurObject();
            theObject.Load(intObjectId);

            AddObject(theObject, htObjects);
         }
      }
   }
}
finally
{
   if ((null != sdrObjects) && (false == sdrObjects.IsClosed))
   {
      sdrObject.Close();
   }
}

When I examined the logs I found that the SQL exception was being thrown in the loop over sdrTrades.Read(). So, I added a bunch more log entries to track exactly where things were breaking down since I could not trace things in the debugger. What I found was quite intriguing.

I discovered that if I put a log entry in the finally block that the code worked as expected; even in release mode. This is very odd considering that the actual exception was being thrown in the try block above. As I was explaining this to a friend of mine I told him that it seemed as if this were some sort of code generation error. Then it hit me: this piece of code didn't have a catch block.

So, I went back and added a catch block to the above code and walla! It worked in both debug and release mode. Furthermore, it didn't matter how much or how little error code I put in the catch block or whatever other changes I made to the code. As long as the catch block was in place the code works in both debug and release modes with out any strange errors.

I would really like to go back now and examine the IL code for both of the cases to see exactly what is going on. However, I don't have the time right now to do that because we are trying to get a product out the door. If I find the time in the future I'll post the results of that research here.

So, if you find yourself with a strange SQL exception in your C# code that only happens when you compile for release mode, you might just check to see if you are using a try / finally block without the catch. If you are, this might just be what is happening to you also.

We are told in Galatians 6:2 — "Bear one another’s burdens, and thus fulfill the law of Christ". I saw this lived out yesterday before my very eyes. People gave of their time, reources and money without ever being asked. None of this can come close to taking away the pain of losing a child. However it can take away a large portion of the other stress associated with such an event.

I didn't have this blog in place at the time we received text for the ESV from Good News Publishers. So, I wanted to put the announcement up here now.

We have the full text of the ESV and are working to get it prepared to work with i-Know It Bible Memory. I will post another announcement here as soon as it is available.

Thank you Good News! We're looking forward to working with you.

We just received the full text of "The Message" from NavPress today! We will now begin work needed to prepare that text to work with i-Know It Bible Memory. I'll post another announcement here as soon as it is available and ready to ship!

Thank you NavPress! We're looking forward to working with you.

I have spent days trying to figure out why my Visual Studio 2003 debugger hangs when trying to debug an ASP.NET application. The symptoms are that after pressing the debug button the application will act like it is going to get into debug mode, but it hangs somewhere in the process, never quite launching the application and never quite returning back to normal when the stop debugging button is pressed.

The error message I was receiving said something like "Auto-attach to process" aspnet_wp.exe Failed. Error code 0x80010012.

After searching and searching newsgroups online, I finally found one small line of advice that solved all of the problems. It simply read: "Sometimes enabling Unmanaged Debugging in your ASP.NET project settings will cause Visual Studio to hang." Walla! Eureka! that was it!

Last week I was trying to debug some historical COM objects and tried turning on this option to see if I could step into that code. However, I had forgotten that I had enabled this and have been struggling ever since.

Praise the Lord for this person who left the advice above. You made my week!

This is probably not a big deal to anyone else, but I'm super excited to annouce that the i-Know It Blog is back up and running. After several months of it being offline, I'm looking forward to posting here again... even if I am the only one that reads it.

Today I was pleasantly surprised to find out that Alaska Airlines places a prayer card on each meal tray that they serve. As Christians we should all strive to reach those whom we do business with. We can't make them believe, but we can be sure they have heard the good news. for "WHOEVER WILL CALL ON THE NAME OF THE LORD WILL BE SAVED." How then will they call on Him in whom they have not believed? How will they believe in Him whom they have not heard? And how will they hear without a preacher? How will they preach unless they are sent? Just as it is written, "HOW BEAUTIFUL ARE THE FEET OF THOSE WHO BRING GOOD NEWS OF GOOD THINGS!" However, they did not all heed the good news; for Isaiah says, "LORD, WHO HAS BELIEVED OUR REPORT?" So faith comes from hearing, and hearing by the word of Christ.

Nice work Alaska Airlines!

I was actually led to the Alaska Airlines article after reading that In-N-Out Burgers puts a scripture reference on the cups and wrappers for their burgers. This has apparently raised some concerns among the conspiracy minded that some religious sect is behind the hamburger chain. <Gasp!> Perhaps they are.

Perhaps we should encourage them to continue and to even be more vocal in the proclamation of God's truth to their customers. Perhaps each of us as Christians should look at our jobs as our mission field and do whatever we can to let the world know that Jesus loves them and has paid the penalty for their sin. Perhaps we're not doing anyone any favors by letting them believe if they live a good life they're going to Heaven. Perhaps if they are looking at us wondering "Well, if they really believed what they say the believe, why don't they act like it?"

I've never even heard of In-N-Out Burgers before today, because they're not around where I live. However, you can be sure I would give them my business if they were. And if I ever have the opportunity Alaskan Airlines will be the airlines I fly. Thank you to both of these companies for sharing Christ with a lost and dying world.