but When i check in summary.txt at this path below
The product version is different which 13.2.5698 as below
Can anyone advise me why it's different in summary.txt files
Best Answer
It appears that, in the summary.txt log file, that second build number is used to indicate the service pack level.
13.0.5698.0 is SQL Server 2016 SP2 CU12. Summary.txt replaces that bolded 0 with a 2 to indicate it's SP2.
I double checked this on a few of my instances of SQL Server, and it seems to hold true for SQL Server 2016 and 2014 consistently. For instance, I have a SQL Server 2014 SP2 GDR instance installed locally, and Summary.txt shows the patch level as 12.2.5223.6, even though the real build number (per @@VERSION) is 12.0.5223.6.
The details of what is in Summary.txt aren't documented per se, so it's probably best to rely on SELECT @@VERSION rather than the contents of that file.
622 is an internal intermediate version, never released. How come you have an 622 version DB? The explanation is simple actually: an aborted upgrade. Look at the sequence Aaron posted:
Converting database 'x' from version 611 to the current version 655.
Database 'x' running the upgrade step from version 611 to version 621.
Database 'x' running the upgrade step from version 621 to version 622.
Database 'x' running the upgrade step from version 622 to version 625.
If the last step above crashes, your database is a version 622 now (each step commits). This version can only be attached to a SQL Server 2008 (or newer) to continue and finish the upgrade. It seems to me you had a SQL Server 2005 DB (v. 611) you attached to a SQL Server 2008 or higher, it started to upgrade but the upgrade failed at step 622->625 and now you're trying to attach it back to the SQL 2005 instance. It can't be re-attached, your only chance is to try to move forward. If the upgrade continue to fail, you will have to start again from an original SQL 2005 database (a copy of the files, a backup...).
Why would a database upgrade fail? Same reason any operation can fail: CTRL-C, power outage, corrupted original database, hardware problems, bugs in the product. Knowing what the upgrade step 622-625 does, my moneys are on a corrupted source DB. Recovering from a failed upgrade is a bit more tricky. As usual, having a good, tested, backup and restore strategy pays off.
I may have a solution for you.
You should go to the registry and delete the registry key below:
HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations
I've created PS scripts for upgrading SQL Server Instances.
Here an example:
# Select the source path and the Instance name.
# Launch the script on a PowerShell console as Administrator.
$SourcePath = "\\MYNAS\Sources\SQL Server 2014"
$InstanceName = "MYINSTANCE1"
Set-Location $SourcePath
$exists = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations" -ErrorAction SilentlyContinue
If (($exists -ne $null) -and ($exists.Length -ne 0)) {
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations"
}
.\setup.exe /ACTION="Upgrade" /Q /INDICATEPROGRESS="True" /INSTANCENAME=$InstanceName /IACCEPTSQLSERVERLICENSETERMS
$InstanceName = "MYINSTANCE2"
Set-Location $SourcePath
$exists = Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations" -ErrorAction SilentlyContinue
If (($exists -ne $null) -and ($exists.Length -ne 0)) {
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "PendingFileRenameOperations"
}
.\setup.exe /ACTION="Upgrade" /Q /INDICATEPROGRESS="True" /INSTANCENAME=$InstanceName /IACCEPTSQLSERVERLICENSETERMS
Best Answer
It appears that, in the summary.txt log file, that second build number is used to indicate the service pack level.
13.0.5698.0 is SQL Server 2016 SP2 CU12. Summary.txt replaces that bolded 0 with a 2 to indicate it's SP2.
I double checked this on a few of my instances of SQL Server, and it seems to hold true for SQL Server 2016 and 2014 consistently. For instance, I have a SQL Server 2014 SP2 GDR instance installed locally, and Summary.txt shows the patch level as 12.2.5223.6, even though the real build number (per
@@VERSION
) is 12.0.5223.6.The details of what is in Summary.txt aren't documented per se, so it's probably best to rely on
SELECT @@VERSION
rather than the contents of that file.