Grant Killian's Blog

February 2005 - Posts

• Are you an Enterprise Manager Addict?

  I sure am.  It's so much easier than remembering all the SQL syntax for editing tables, setting up indexes, etc.  I learned this -for about the 100th time in my career- over the last week when we started to get the invalid cursor state errors identified in this KB article: http://support.microsoft.com/default.aspx?scid=kb;en-us;831997 We're not sure why it started, but last week any data schema changes we made through Enterprise Manager would fail and give us the above error.  We could make our changes in SQL Query Analyzer, sure, but using that philosophy I should be writing my .Net code in Notepad and compiling from the command line instead of using VS.Net.  Just because you can do something doesn't mean you should.  SQL Enterprise Manager is a huge productivity boost and frees my brain from remembering the SQL syntax for indexing and other dba minutia.  It took about 3 days of prodding before the powers-that-be relented and decided getting the hotfix was the way to go; they were understandably concerned about having a non-standard database build on the server, but I dare you to show me a truly "standard" db build except for one that comes straight from the installation disk.  Applications are installed, uninstalled, and updated over time and dlls, the registry, and other services get configured so that eventually a server is a complicated spider web of deviations from "the norm."  It does concern me, however, that this hotfix isn't freely down-loadable from the web . . . just the sort of thing that might bite us in the butt when we're making changes to other parts of the server.  Regardless, we jumped through the hoops with Microsoft Dev Support (1-800-936-5800) and got the hotfix and resolved the issue.  Enterprise manager is back and I can dump any of that SQL admin syntax that my short term memory may still be storing! Posted Feb 14 2005, 12:46 PM by grant.killian with 1 comment(s)

• CodingWorse (at least slightly) with MsgBox

  My previous post pointed out the shortcomings of using Try-Catch blocks to handle situations that are not truly exceptional.  In the same vein I offer this opinion on the VB.Net MsgBox() function -- note I say opinion because this time I don't have the astounding perf numbers to back me up.  Here goes . . . I was eating dinner tonight and showing a friend of mine a little VB.Net code.  Yes, that's right -- a buddy stopped by and we were huddled around the laptop for a little nerdery and eggplant parmesan.  This friend of mine does some Access development and I've been working on bringing him into the .Net fold.  We got sidetracked for about 30 minutes on why I don't use MsgBox() and, instead, use MessageBox.Show().  While some will say it's only a matter of preference, I think it's more than that.  MsgBox is the Visual Basic wrapper around the .Net Framework's MessageBox.Show method -- there is a tiny bit more overhead to MsgBox, but it's negligible especially when you consider you're halting your program to display a dialog box to the user!  I can't really play the perf card here. I think my two main issues with MsgBox are: It reminds me of old VB6 and VBA days (like with Access); it carries a stigma of belonging to a bygone era.  Comparing the IL for functions with MsgBox() and MessageBox.Show() is strikingly different: the MsgBox alternative calls into Microsoft.VisualBasic while MessageBox.Show() calls System.Windows.Forms.  This might be a very very academic point, but I just get a warm and fuzzy feeling with System.Windows.Forms compared to Microsoft.VisualBasic. I do a lot of C# programming and there's no MsgBox there!  By learning the true .Net Framework I'm making my life easier -- it's more like I'm programming in only one language instead of VB.Net sometimes and C# at other times.  I think Jeff Richter of Wintellect was the first to proclaim that all .Net developers are really programming in the same language.  The Base Class Library is common to all .Net developers and the type systems can be coded the same (I could use System.Int32 instead of int or Integer -- and I did that for a while until I decided that was taking things too far).  I can use the Show method of the MessageBox object in any .Net compliant language (even with Darrell's recent Python fixation!). Call me a snob, but I know if I was reviewing code for a new hire and saw MsgBox() in their VB.Net code, I'd have a slightly -- just ever so slightly -- lesser opinion of the code.  If it came down to two identical candidates, one MsgBoxer and one MessageBox.Shower, I'd hire the MessageBox.Shower for sure.  MSDN even says MessageBox.Show is preferred.  I realize this is hardly a CodingWorse scenario on par with the previous try-catch transgression, but MsgBox just rubs me the wrong way.    Posted Feb 02 2005, 08:36 PM by grant.killian with 11 comment(s)