Recently, one of my blog readers contacted me with an issue they faced after downgrading their SQL Server edition from Enterprise Evaluation to Standard. They found that their database was no longer accessible. To troubleshoot the problem, I asked them to share the SQL Server ERRORLOG. In this article, I will explain how to read the ERRORLOG and discuss the possible causes and solutions for this issue.

Reading the ERRORLOG

To read the ERRORLOG, follow these steps:

1. In Object Explorer, expand the server, then expand Management, and finally expand SQL Server Logs.
2. Right-click on a log and select “View SQL Server Log”.

Alternatively, you can refer to Balmukund’s blog post on “Help: Where is SQL Server ErrorLog?” for more ways to access the ERRORLOG.

Once you have accessed the ERRORLOG, look for any error messages related to the inaccessible database. In the case of my reader, they shared the following messages:

2015-02-20 13:47:36.65 spid7s      Error: 905, Severity: 21, State: 1.
2015-02-20 13:47:36.65 spid7s      Database 'My_Database' cannot be started in this edition of SQL Server because it contains a partition function 'myRangePF1'. Only Enterprise edition of SQL Server supports partitioning.
2015-02-20 13:47:36.65 spid7s      Error: 933, Severity: 21, State: 1.
2015-02-20 13:47:36.65 spid7s      Database 'My_Database' cannot be started because some of the database functionality is not available in the current edition of SQL Server.

Understanding the Issue

From the error messages, it is clear that the database is using a partition function, which is an enterprise-only feature. The Standard edition of SQL Server does not support partitioning, hence the database cannot be started correctly. It is important to note that not all editions of SQL Server support partitioned tables and indexes. You can refer to the “Features Supported by the Editions of SQL Server” topic in the Books Online for a complete list of features.

Solution

To resolve this issue, I advised my reader to restore the database MDF and LDF files to another instance that is either a developer, enterprise, or enterprise evaluation edition. Once restored, they need to remove any features that are specific to the enterprise edition. To identify these features, they can use the DMV (Dynamic Management View) sys.dm_db_persisted_sku_features.

USE <DatabaseName> -- Replace with the name of the database in question
GO

SELECT * FROM sys.dm_db_persisted_sku_features

Note that this query should be run in the database under question, not the master database. The result of this query will show the features that need to be removed. Once the objects referring to these features are removed, a backup can be taken and restored on a “lower” edition of SQL Server.

It is worth mentioning that downgrading the edition of SQL Server, even from evaluation to standard, can be considered a downgrade because certain features available in the enterprise edition may not be available in the standard edition. Therefore, it is always advisable to run the DMV and check for any features that may cause issues during the downgrade process.

Have you ever encountered any downgrade scenarios and faced similar errors? Share your experiences in the comments below!