Downgrade SQL Server 2012 from Standard Edition to Developer Edition


We have several dev/test servers with SQL Server 2012 Standard edition installed. Since Developer edition is free for development/test environment, so it make sense to downgrade to Developer edition. Unfortunately, Microsoft does not provided a direct method to do it. According to Microsoft online book:, it is easy to upgrade from cheaper edition to expensive edition, not the other way around.


We will have to uninstall SQL Server 2012 Standard edition, then install Developer edition. But before doing that, we can backup the system databases, then migrate them later into the new installation.


  1. Preparation: check the instance properties and system database properties, take a screenshot of the root directory and database default locations.database-setting1
  2. Run  SQL Server 2012 Configuration Manager, take a screenshot of accounts used by SQL Server services, then stop the services.
  3. Copy system databases (master, model, msdb) and ReportServer database to a new folder.
  4. Uninstall SQL Server 2012 Standard edition.
  5. Install SQL Server 2012 Developer edition, set the root directory and database default locations the same as the previous installation. Make sure the patch level is the same as before.
  6. Run SQL Server 2012 Configuration Manager, stop SQL Server services.
  7. Copy the system databases (master, model, msdb) and ReportServer database from the backup folder to the current installation folder.
  8. Restart SQL Server services.

Trouble Shooting for “No global profile is configured”


A weekly maintenance plan failed this weekend. I checked the history of the maintenance job, and found the following error message:

01/29/2017 21:13:00, MaintenancePlan.Sundays, Error,, SQL001, MaintenancePlan.Sundays,,, The job failed.  The Job was invoked by Schedule 39 (! DBA – MaintenancePlan.Sundays).  The last step to run was step 1 (Sundays).,00:00:04,0,0,,,,0

01/29/2017 21:13:00, MaintenancePlan.Sundays, Error,1, SQL001, MaintenancePlan.Sundays, Sundays,, Executed as user: NT Service\SQLSERVERAGENT. Microsoft (R) SQL Server Execute Package Utility  Version 12.0.5000.0 for 64-bit  Copyright (C) Microsoft Corporation. All rights reserved.    Started:  9:13:00 PM  Progress: 2017-01-29 21:13:01.80     Source: {06474EBF-18F1-49F5-960B-B11B5686CA69}      Executing query “DECLARE @Guid UNIQUEIDENTIFIER      EXECUTE msdb..sp…”.: 100% complete  End Progress  Error: 2017-01-29 21:13:02.40     Code: 0xC002F210     Source: Notify Operator Task Execute SQL Task     Description: Executing the query “EXECUTE msdb.dbo.sp_notify_operator @name=N’The DB…” failed with the following error: “No global profile is configured. Specify a profile name in the @profile_name parameter.”. Possible failure reasons: Problems with the query “ResultSet” property not set correctly parameters not set correctly or connection not established correctly.  End Error  Warning: 2017-01-29 21:13:02.40     Code: 0x80019002     Source: Sundays      Description: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED.  The Execution method succeeded but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.  End Warning  DTExec: The package execution returned DTSER_FAILURE (1).  Started:  9:13:00 PM  Finished: 9:13:02 PM  Elapsed:  2.464 seconds.  The package execution failed.  The step failed.,00:00:04,0,0,,,,0


The reason is that the database mail profile we have configured, is not the global/default any more. Change the profile to “Default” will fix the problem.


1. Right click Database Mail, select Configure Database Mail from the right-click menu.


2. Select Next on the Database Mail Configuration Wizard window. configure-db-mail21

3. Select Manage profile security in the window.


4. Select Yes, then Next in the Default Profile field.

configure db mail41.jpg

5. Select Finish to complete the configuration in the next window


Trouble Shooting for Error 7311 and Error 7412


We have an ETL job which failed recently, an alert was sent to us:

SQL Server Job System: ‘XXX-XXXXX’ completed on \\SQL001

JOB RUN:            ‘XXX-XXXXX’ was run on 1/1/2017 at 0:00:00 PM

DURATION:         0 hours, 10 minutes, 1 seconds

STATUS:               Failed

MESSAGES:         The job failed.  The Job was invoked by Schedule XX (Morning).  The last step to run was step 1 (YYYYY_YYY).


Start SSMS, expand SQL Server Agent – Jobs, right click on the job ‘XXX-XXXXX’, select “View History” from the right-click menu.

The job runs daily, 60% succeeded, 40% failed. For the failed jobs, there are this error message in the log”

“Cannot obtain the schema rowset “DBSCHEMA_TABLES_INFO” for OLE DB provider “SQLNCLI10” for linked server “SQL002”. The provider supports the interface<c/> but returns a failure code when it is used. [SQLSTATE 42000] (Error 7311)  OLE DB provider “SQLNCLI10” for linked server “SQL002” returned message “Unspecified error”. [SQLSTATE 01000] (Error 7412)  OLE DB provider “SQLNCLI10” for linked server “SQL002” returned message “Query timeout expired”. [SQLSTATE 01000] (Error 7412).  The step failed.,00:10:00,16,7412,,,,0″

Since it sometimes works properly, sometimes not, so adjusting the parameter for remote query timeout Server Configuration Option of the linked server may fix the issue. The default value is 600 (seconds). I changed it to 3000 (seconds), resolved the issue. It can be done by two methods:

Method 1 Using SQL Server Management Studio

  • In Object Explorer, right-click the linked server and select Properties.
  • Click the Connections node.

Under Remote server connections, in the Remote query timeout box, type 3000.


Method 2 Using T-SQL

USE Database1;


EXEC sp_configure ‘remote query timeout’, 3000 ;




Trouble Shooting for Error 8152 and Error 3621


We have an ETL job which failed recently, an alert was sent to us:

SQL Server Job System: ‘XXX-XXXXX’ completed on \\SQL001

JOB RUN:            ‘XXX-XXXXX’ was run on 1/1/2017 at 0:00:00 PM

DURATION:         0 hours, 3 minutes, 37 seconds

STATUS:               Failed

MESSAGES:         The job failed.  The Job was invoked by Schedule XX (Night).  The last step to run was step 1 (EXECUTE [DBXXXXX].[dbo].[SPXXX]).


Start SSMS, expand SQL Server Agent – Jobs, right click on the job ‘XXX-XXXXX’, select “View History” from the right-click menu.

This error message can be found in the log:

“START:[Table001] [SQLSTATE 01000] (Message 50000)  String or binary data would be truncated. [SQLSTATE 22001] (Error 8152)  The statement has been terminated. [SQLSTATE 01000] (Error 3621).  The step failed.,02:06:11,16,3621,,,,0”

This error is usually caused by the inserting data (VARCHAR or CHAR data type) is longer than the length of the column in the destination table. In our case, this statement in SP [DBXXXXX].[dbo].[SPXXX] caused the problem:

INSERT INTO [DBXXXXX].[dbo].[Table001]






from [SQL002].[DBYYYYY].[dbo].[Table001]

where identity_column > @V1

The length of columnA in destination table is 20, is 2 in source table. The solution is to change the length of columnA  in destination to 20. Then the job ran successfully.

Patching SQL Server 2014 Failover Instance

We have a SQL Server 2014 failover instance need to patched. The failover instance include 2 nodes — SQL001 (active) & SQL002(passive), the build before patching is RTM with no service pack and cumulative update installed. The patch is cumulative update 14 for RTM.

Install CU 14 on SQL Server 2014 Failover Instance

Step 1. Install CU 14 on passive node (SQL002)

We will install CU 14 on the passive node first.

  1. Login to the passive node SQL002, run “SQLServer2014-KB3158271-x64.exe” to install CU 14.install-cu14
  2. Accept  License Termsinstall-cu14_1
  3. Select the features to be installed.install-cu14_2
  4. Select “Next” when files in use check completed.install-cu14_3
  5. Select “Update” to start installation.install-cu14_4
  6. Select “Close” when installation completed.install-cu14_5

Step 2 Manually Failover

In order to patch SQL001, we will manually failover to SQL002, and make SQL001 passive node.

  1. From Server Manager, select “Tools” — “Failober Cluster Manager”.failover-cluster-manager2
  2. Select the cluster name in Failober Cluster Manager, then click “Roles” — “SQL Server (MSSQLSERVER)”, select “Move” — “Select Node…” in Action panel.failover-cluster-manager3
  3. Select SQL002 in the Move Clustered Role window.
  4. In Roles panel, the Owner Node will change to “SQL002”, the Status change to “Pending”.failover-cluster-manager5
  5. The failover is completed when the Status change to “Running”.failover-cluster-manager6

Step 3 Install CU 14 on SQL001

  1. Install CU 14 on SQL001 follow the procedure in Step 1.
  2. After installation completed, manually failover to SQL001. The installation completed.


Troubleshooting for “The transaction log for database ‘database1’ is full due to ‘REPLICATION'”


I have a dev/test server B on which one database [database1] was restored from the same name database on production server A. [database1] on server A is the published database in a transnational replication. The recovery mode is simple for [database1] on both servers.

Recently I have received an alert from server B:

“Title: SQL Server Alert System: ‘server B – Sev:017 – INNSUFIFIENT RESOURCES’ occurred on \\server B 

DESCRIPTION:   The transaction log for database ‘database1’ is full due to ‘REPLICATION’.”


First I checked the transaction log file size and available disk space, the log is 200GB, and the drive is almost full. The recovery mode of [database1] is simple, which means the transaction log should be truncated automatically.  However, some factors may delay the truction, they are explained in the online book:                 

Run this script (script1) to get the factor:

SELECT [name]
FROM [sys].[databases]
where name = ‘database1’

The result is


The factor delayed the truncation is REPLICATION. But there is no replication setup on this server at all. I verified that by running this script:

SELECT [is_published]
FROM [sys].[databases]
where name = ‘database1’


Then I checked the transaction log file usage by running the command: “DBCC SQLPERF(logspace)”. The result of “log Space Used(%)” is more than 99%, which means it can’t be shrunk to a reasonable size.

I tried stored procedure sp_removedbreplication:  

exec sp_removedbreplication ‘database1’

It did not remove the replication flag on database. Restoring from a published database may just bring partial information of the replication, enough for SQL Server not to truncate the tranction log, not enough for sp_removedbreplication to find and remove it.

So the solution is to add the database to publication, then remove it. Right click Replication in SSMS, then click Publisher Properties. Click Publication Databases in the Publisher Properties window, and check the Transactional button besides [database1], then OK.



Ran script1 again and found the value of [log_reuse_wait_desc] changed to “NOTHING”, which means nothing will delay the truncation of transaction log. Ran “DBCC SQLPERF(logspace)” again, “log Space Used(%)” is 0.09. Then you can just shrink the transaction log file and solve the problem. The last step is to go back to Publisher Properties, and uncheck the Transactional button besides [database1].