How to Activate Microsoft SQL Server 2008 R2 180-day Evaluation Version After Expiration with a Product Key (Step-by-step)

The trial period of the Microsoft SQL Server 2008 R2 180-day Evaluation version had come to an end on my laptop and the SQL Server had stopped working. I had bought the Developer Edition media with product key and wanted to use that to have the SQL Server running again. The following are the step-by-step screenshots of the entire activation experience.

Click on images to enlarge.

Following is the error message that comes up while trying to start the SQL Server Management Studio on an expired SQL Server 2008 R2 showing that the trial period has expired.

1.ErrorMessage

I have Windows 7 Home Premium (64-bit) running on Intel Core 2 Duo 2.2 GHz, 4 GB RAM. To begin the activation, go to Start > All Programs > Microsoft SQL Server 2008 R2 > Configuration Tools > SQL Server Installation Center (64-bit). Go to Maintenance and click on Edition Upgrade.

2.SQLServerInstallationCenter

An in-progress message appears briefly.

3.InProgress

A setup rule verification window appears and shows the progress while the rules are verified. Each status message can be checked by clicking on the link. A summary of all the rules is also presented in HTML format. The path for the HTML file is mentioned at the end of the blog post. Wait for the setup to verify the rules to and click OK.

4.SQLServer2008R2SetupWindow1

Another set of rules are verified. Wait for this to complete and click Next.

5.SQLServer2008R2SetupWindow2

The next screen presents an option to enter the product key. Enter the key and click Next.

6.UpgradeTheEditionForSQLServer2008R2ProductKeyWindow

Read and accept the license terms by checking the checkbox. Click Next.

7.UpgradeTheEditionForSQLServer2008R2EULAWindow

Select the SQL Server instance from the dropdown and click Next.

8.UpgradeTheEditionForSQLServer2008R2SelectInstanceWindow

One more set of rules are verified. After completion click on Next. The next window shows a summary for review and a confirmation that the setup is ready to upgrade the edition. Click on Upgrade. The Upgrade button will be disabled but there will not be any other activity indication like a hour-glass cursor or a progress bar. This could be a little puzzling but wait for it to complete. It took about 4 minutes to complete on my laptop. Your mileage could vary.

10.UpgradeTheEditionForSQLServer2008R2_ReadyToUpgradeWindow

The final screen shows a completion message and the path of the setup log file. Click on the log file path to open it. Click OK on the setup window to close it.

11.UpgradeTheEditionForSQLServer2008R2_CompleteWindow

HTML report of the setup rules:
C:Program FilesMicrosoft SQL Server100Setup BootstrapLogYYYYMMDD_HHMISSSystemConfigurationCheck_Report.htm

Text log files:
C:Program FilesMicrosoft SQL Server100Setup BootstrapLog
and its child folders.

Comments in SQL and a case for multi-line vs single-line comments

Developers use comments within the code primarily for two purposes –

  • Documentation (for posterity)
  • Debugging (making quick comparisons of the impact of a change without discarding the original code)

It depends on the team’s culture and their coding standards as to how much they choose to comment for documentation. Ideally, there should be a change history included as a header at the top of the code and additional comments to highlight why a particular logic was used. Another developer (or even the original) can look at the code and understand what is it doing, but sometimes it is not apparent why was that particular implementation chosen over others. So it is a good idea to mention the rationale behind using a particular logic. Other interesting paradigms can be checked on the Wikipedia article on Comments in Programming.

TSQL supports two types of comments –

  • Single-line comments: These start with a double hyphen ‘- -‘ and the rest of the code on that line till the new-line (or carriage return) character is considered to be a comment.
  • Multi-line comments: These start with a ‘/*’ and end with a ‘*/’ either on the same line of the code or on another line and everything in between these two is considered to be a comment.

The implementation of comments has not changed much between various editions of SQL Server but there have been few considerations. The MSDN article for comments syntax in SQL Server 2000 mentions that comments cannot span multiple batches. If the batch delimiter keyword GO is within a multi-line comment then the ending */ will not be parsed correctly and cause syntax errors. The SQL Server 2005 or later versions could have issues when the ‘*/’ string is put in a multi-line comment. Try the code below in SQL Server 2005 or later versions to see an example –

DECLARE @s VARCHAR(10)
/*
SET @s = '*/'
*/
SELECT @s

Each comment type has its uses but I personally prefer and recommend using the multi-line syntax, even for short comments that could fit on a single line. My reason for that is that I frequently get requests to review queries and give suggestions on tuning them. Sometimes that query has been captured from DBCC INPUTBUFFER(spid) or the dm_exec_sql_text(sql_handle) DM function. Both of these do not preserve any formatting of the code. As a result I get the entire stored procedures’ code in one single long line!

I usually try to format such code using an excellent online code formatter by the name of SQLInForm. When the formatter comes across a double hyphen, it considers the rest of the line as a comment and leaves it as it is. At that point I have to make a choice either to painfully go through the remaining code and try to guess what is a comment and what is not. At times I send it back to the developer to provided a better fomatted code. Both these approaches increase the turnaround time for the whole tuning process.

If the developer had used the multi-line comment syntax in the first place, then the code formatter could have handled it and life would have been much easier.