http://dotnet.sys-con.com/ Latest articles from Scott Golightly Copyright 2008 .NET DEVELOPER'S JOURNAL Sun, 20 Jul 2008 16:38:00 GMT .NET DEVELOPER'S JOURNAL 10 http://backend.userland.com/rss http://dotnet.sys-con.com/read/159557.htmhttp://dotnet.sys-con.com/read/159557.htm Thu, 08 Dec 2005 11:30:00 GMT Every person who has ever been responsible for backing up data has had to ask themselves the same basic questions. They need to know what data has to be backed up, how frequently it changes, where to store the backups, and how quickly the data will have to be restored in case of disaster. The answers to these questions in a large way determine the media used to back up the data and the ultimate storage location for the backup. It seems that every day we read about a hurricane, fire, flood, or other disaster. Couple the natural disasters with the need for 24x7 availability and increasing government regulation and it's easy to understand why the disaster recovery plans of an organization are coming under scrutiny. For years the general pattern was to back up data to tape and store those tapes onsite in a vault or offsite in a secure location. But several recent developments have started people looking at other alternatives. http://dotnet.sys-con.com/read/46341.htmhttp://dotnet.sys-con.com/read/46341.htm Mon, 13 Sep 2004 00:00:00 GMT At one time or another, most applications have to determine when a certain subroutine or function is executed and inform the user when an important event or an error occurred. Over the years, clever developers created different methods for these kinds of notifications. At some point in time, just about every Visual Basic programmer has tried using a message box to show when a method or subroutine was called. While this technique might work well for debugging, it's highly error-prone. Because there are legitimate times when a message box should be shown to the user, the developer can't just comment out every call to MessageBox. http://dotnet.sys-con.com/read/45539.htmhttp://dotnet.sys-con.com/read/45539.htm Tue, 06 Jul 2004 00:00:00 GMT In the early 1990s, I was working on a project in which we were creating an accounts receivable system. Because the users of the system would be dealing with people whose accounts were past due, the major concern of the client was that the windows open as quickly as possible. The ultimate goal was to have the main window in the application open in three seconds or less. We tried our best to optimize the application by removing unnecessary code from the window initialization code and optimized the database with appropriate indexes.