May 2004 - Posts

• Virtual Desktop Manager

  I've been tinkering with Linux lately and one of my favorite KDE features is the desktop switcher.  Tonight I found Virtual Desktop Manager, a Microsoft PowerToy that does basically the same thing.  It looks promising so far. Update:  This thing was really flaky until I upgraded my RAM to 1GB.  As Girish pointed out, it would freeze under low memory conditions.  Also, one of my biggest gripes is that if I have VS.NET maximized on desktop #1, switch to a different desktop, and then come back to desktop #1, VS.NET will no longer be maximized.  Nothing major...just a pain in the butt. Posted May 19 2004, 08:34 PM by bkcarroll with 2 comment(s) Filed under: .NET Related, General

• Book Gripe

  While reading chapter 4 of the MSPress “Inside Microsoft Visual Studio.NET“ book, I ran across this paragraph: “By right-clicking on a macro in Macro Explorer, you can bring up a shortcut menu that lets you work with the macro directly.  The Run command executes the Tools.Run command on the currently selected macro.  The Rename command allows you to edit the name of the macro in place.  The change you make to the name is reflected in the method name in the Macros IDE.  The Delete command deletes the currently selected macro.  And finally, the Edit command opens the current macro in the Macros IDE.” Now come on...who is the intended audience for this book?  I've never written a book, but I have taught several Microsoft developer classes and appreciate the difficulty of gearing content to a wide range of skill levels at one time.  But is it really necessary to go to such a low common denominator?  Surely anyone reading this book knows how to use a GUI and will understand that the delete command will delete the currently selected item.  Nevertheless, I've skipped all around this book getting the pieces I need and other than these types of annoyances, it's a very informative book. Posted May 13 2004, 04:25 PM by bkcarroll with no comments Filed under: .NET Related, General

• Be careful using a datetime column as part of a primary key

  For no appartent reason an app that had worked fine for two years all of a sudden started failing with primary key violoations.  Of course I had “optimized“ it shortly before it started failing, but  I didn't see how my changes could have caused this problem.  I only removed a few lines of code and didn't change anything related to data access.  My change was intended to make the code run faster, but nothing else.  Well, my changes sped it up and that's exactly what was wrong.  Because it was running faster, data was being written to the database more often.  One of the fields being written was “LastUpdate“ which was defined as datetime data type and was part of the primary key.  The datetime data type in SQL Server is only accurate to one three-hundredth of a second, so although the app may have been passing two different values to SQL server for consecutive records, the values were being rounded which was causing the primary key violation.  For example, assume I pass these values to a stored procedure: 2004-05-13 13:12:19.393 2004-05-13 13:12:19.394 2004-05-13 13:12:19.395 2004-05-13 13:12:19.396 2004-05-13 13:12:19.397 SQL Server rounds them to this: 2004-05-13 13:12:19.393 2004-05-13 13:12:19.393 2004-05-13 13:12:19.397 2004-05-13 13:12:19.397 2004-05-13 13:12:19.397 It's easy to see how this was causing my problem.  SQL Server always rounds to .000, .003, or .007 milliseconds. I found no reason to have the LastUpdate field as part of the primary key, so I removed it and all worked well.  Another lesson learned! Posted May 13 2004, 01:35 PM by bkcarroll with no comments Filed under: .NET Related

• Truncating and Shrinking a SQL Database Log

  I don't do this often enough to remember, but I've included it here for future reference.  I find that I usually only need to do this when a client fails to backup their transacation logs for a while and then they call (in panic) because they have run out of drive space.  Truncate the log to the oldest transaction: BACKUP LOG dbname WITH NO_LOG To make the transaction file physically smaller, issue this command: DBCC SHRINKFILE ('logical filename', target MB) If the backup doesn't seem to shrink the log file as much as expected, issue the following command to see the open transactions: DBCC OPENTRAN('dbname') Posted May 13 2004, 10:48 AM by bkcarroll with no comments Filed under: Scratch Pad