Data Driver

Blog archive

When Beta Apps Wreck Your System: A SQL Server 2008 R2 Eval Lesson

OK, I need a little help here. I earlier wrote about a nightmare I endured (along with many others) with the evaluation version of SQL Server 2008 R2.

I was surprised to be ripped by readers. Turns out it was my fault. You're never supposed to install beta apps on a system you might want to use again. That was news to me. One reader wrote:

"By its very nature eval software is not to be installed on any machine you don't care about needing to be rebuilt from the ground up. Hasn't anybody ever read the warnings included with installation of eval software? If you are "experimenting" with new software on a machine that cannot be wiped and rebuilt then the onus is on YOU not Microsoft."

Another concurred:

"When using evaluation software you should always walk in the path that what you are installing it on may not be capable of running afterwards, no matter who wrote the software."

How did I miss this? Where are these "warnings"? Do Microsoft or other major vendors actually say that you should only use this stuff at your own risk because it might trash your computer? I looked around quickly on Microsoft's site but didn't see these warnings. Do they pop up when you install the software or are they in the EULA or somewhere else? I'd test this out by installing something and seeing what warnings I receive, but I'm afraid to now. Maybe I just click too quickly through all the screens during setup and have missed these warnings.

Anyway, reader No. 1 suggested using virtual machines. I've never tried these, frankly, so I'm looking for some advice. He mentioned a free server from Microsoft, what I presume is Virtual Server 2005 R2. Does anybody have any real-world experience with this? I have an underpowered Win 7 laptop so I'm kind of concerned about any additional load it will put on the system. And there must be myriad other details that real users can relate that aren't found in the documentation.

Also, are there any other free alternative virtual servers that anyone has hands-on experience with that might be useful for testing software?

Another reader mentioned he uses partitions for testing this stuff. But I've had bad experiences with partitioning disks before, too (hmm, maybe it's just me). What about you? Any suggestions or experiences to pass along with partitioning, or partitioning vs. virtualization?

So basically I'm looking to share with everyone any tips, warnings or ideas about virtualization or partitioning--or alternative methods to test software--that you'd care to provide. Please comment here or drop me a line.

Posted by David Ramel on 07/21/2011 at 1:15 PM

comments powered by Disqus

Reader Comments:

Mon, Oct 17, 2011 Jay Nashville, TN

Using a virtual machine (VM) is the easiest and cleanest way to test new software, especially betas. I recommend VirtualBox. It's totally free and easy to use, but has advanced features if you need them. Once you've installed an OS you want to test on, you can take a snapshot of it's current state. After testing, you can easily roll back to that prior state. It keeps the beta software quarantined and makes for easy cleanup after you're done.

Tue, Aug 2, 2011 Nathan Collins Cardiff, UK

I would say that Virtualisation is the way to go - partitioning is meddling with your computer more than is required. Virtualising using something like Virtual PC 2007 or Sun's VirtualBox (my preference) is as simple as installing and showing it where the installation media (cd/dvd or ISO) is. It then fires up a "fake PC" (with BIOS and everything) and creates a virtual hard drive in your Documents folder (it's just a single file), it's all very easy, and when you're done - just delete the file and it's all gone, no lasting damage can be done. As a programmer I would definitely say that installing beta software onto a production machine or even just a computer that you intend to continue using is a no-no. I didn't learn this from warnings, just from how software is built - inherently beta software is undertested and can have major bugs/flaws in it. We don't write in all of our unit tests until pre-production, only a fraction, so a lot of the code is just "wing and prayer" stuff.

Add Your Comments Now:

Your Name:(optional)
Your Email:(optional)
Your Location:(optional)
Please type the letters/numbers you see above

.NET Insight

Sign up for our newsletter.

I agree to this site's Privacy Policy.