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.
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.
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!