We were working on TFS2015 and SQL2014. Our plan of this month is upgrading to TFS2017update1 and SQL2016.
I have created a test environment on personal VM. My process :
Back up TFS database in SQL, upgrade SQL2014 to SQL2016
Upgrade TFS2015 to TFS2017update1
Restore the database.
Everything works well except step #3. I was not able to restore the database back to TFS2017. Any suggestions?
The error info:
TF30046: The instance information does not match. Team Foundation
expected 368f7830-1c67-4c4c-8bc4-ba3d5b5a5543 which was not found.
Please contact your Team Foundation Server administrator.
First, suggest you to go through the event log on your machine to see if there are some useful info for troubleshooting.
If you're using SQL Server 2016, we require a Visual C++ runtime
update to be installed.
Double check your environment, make sure you have installed a Visual C++ runtime.
Besides, since you are going to update TFS 2017 Update 1, which the support SQL2016 version minimum is SP1.
TFS version Support SQL Server version
TFS 2017 Update 1 SQL Server 2016 (minimum SP1)
SQL Server 2014
More details please refer TFS Requirements and compatibility.
You could also follow Pero P.'s suggestion,select the Pre-Production upgrade, ignore the restore.
Related
This is probably a trendy question, But I promise you my problem is different.
Lately my server windows crashed and I was forced to install new windows.
I took a backup of the database "ReportServer" and "ReportServerTempDB".
Until then I didn't remember the SQL Server version was installed before the windows crashed.
Now when I try to attach these databases and run the report server, it tells me the following message
"The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is '163'. The expected version is '162'. (rsInvalidReportServerDatabase)"
I've made some research, and understood that my current installed SQL Server version is higher than the database, I tried installing some cumulative updates but when I run the updates it seems not to be recognizing the SQL Server version installed.
Current installed version: Microsoft SQL Server Enterprise: Core-based Licensing (64-bit) 2014 v12.0.2000.8
Previously installed version: Microsoft SQL Server 2012 Enterprise Not sure though.
My problem is that I can't open the ReportServer database because it's version is older and I can't install the right cumulative update to fix this issue. Can anyone point me to the right direction?
Much appreciated Thanksss!!.
We recently updated our production SQL Server 2016 Enterprise instance from SP1 to SP2. We are currently on version 13.0.5026. Prior to the upgrade, a user with connect rights to SSISDB and proper rights on the Integration Services Catalog folder could deploy an ISPAC file successfully.
After the upgrade, the same users can still deploy to the SSISDB, but when you execute the .DTSX, the script task inside fails validation. If I deploy the exact same ISPAC as a sysadmin, there's no issue. The usual solution I've seen is to confirm that SSDT Configuration Properties are set to SQL Server 2016. We have verified this is set correctly prior to building the ISPAC.
I saw a similar issue when migrating from SQL Server 2014 to 2016 a couple years back, but the solution at that time was to give the Proxy account that runs the package modify rights to the C:\Windows\Temp folder so it can generate temp files. This new issue is hard to pin down, and I don't want to give out sysadmin just so others can do the simple deployment steps.
Any thoughts or suggestions are appreciated.
*******Update/edit************:
The server has a SQL Server 2016 deployment tool located under SQL Server/130/DTS/Binn - ISDeploymentWizard.exe. This deployment tool works. There is another identical wizard under the 140/DTS/Binn location, same name but 1 KB larger (assuming this is because SSMS is a separate install now, and I installed latest and greatest on server). This one fails deployment. I'm banging my head against the wall as to why one works but the other doesn't. Locally we all use SSMS 2017, and with that we get the 140/DTS/Binn ISDeployment file, not the 130 (since that's SQL Server 2016 and we're using SSMS 2017, which I thought was backwards compatible). Either way, this problem just started occurring and we've been on the same version of SSMS for a few months.
Image of the Execution information report from SSMS
Had resolved a similar issue with C# scripts recently. In short: don't use 140 version of ISDeploymentWizard.exe with MS SQL 2016. It apparently mangles something in C# code, or components' properties, and 2016 runtime stops recognising them.
In my case, a package with C# script source has started to throw the following error during the validation phase:
Error: Microsoft.SqlServer.Dts.Pipeline.ComponentVersionMismatchException:
The version of C# source component name is not compatible with this
version of the DataFlow. [[The version or pipeline version or both for
the specified component is higher than the current version. This
package was probably created on a new version of DTS or the component
than is installed on the current PC.]]
at Microsoft.SqlServer.Dts.Pipeline.ManagedComponentHost.HostCheckAndPerformUpgrade(IDTSManagedComponentWrapper100
wrapper, Int32 lPipelineVersion)
The first comment here has helped me to ultimately identify the cause.
I was installing TFS 2015 and was never given a chance to choose my database. I already had a SQL Server Enterprise installed and installation "wizard" proceeded to install SQL Server Express and then putting TFS database on it. I am not sure why it works this way, but is there any way to change this??
My TFS has nothing on it, I just installed it. I've read a lot of blogs about moving "Collection" from one DB to another, but I don't want to move the collection (it's empty and it's easy to do through admin console). I am trying to move the actual TFS' internal components from SQL Server Express to SQL Server on the same server.
UPDATE:
For anyone interested in knowing more about/how-to unconfigure TFS: Unconfigure Team Foundation Server
Copy the Tfs_Configuration database SQL Express instance to your full SQL Server instance, then run TFSConfig RemapDBs
An alternative, since you don't have any data: Just unconfigure your app tier and rerun the configuration wizard. Use the advanced configuration wizard and you'll have the opportunity to specify a database instance.
It's also worth noting that you should be installing TFS 2018, not TFS 2015, unless you have a very good reason. 2015 is 3 years old and two major releases behind.
I am developing with BizTalk for the first time. I have created an extremely basic project in VS2103 which builds but fails to deploy with the output:
error DEPLOY: The database or the database version is incompatible with the installed version of this product.
The BizTalk installation is BizTalk 2013 R2 on a SQL Server 2012 SP3 database.
My project is using VS2013 because I understand that VS2105 can't be used to target BizTalk 2013.
There is no further information in the output window. I have a valid login on the database and can perform CRUD operations on it through VS2013.
This page suggests I need "SQL Server Development Tools" - am I right in assuming this means "SQL Server Data Tools" because that's all I seem to get when I search for it.
Even a pointer to where I can find a more more informative error would be useful (perhaps unsurprisingly changing the build verbosity only affects the build output when what I'd like is a more informative deploy output!).
Apparently this issue is related to the OS - BizTalk 2013 (or some other element of my setup) isn't compatible with Windows Server 2012 R2. Downgrading to R1 isn't an option the security team will allow. Upgrading BizTalk means upgrading SQL Server means upgrading some other software we have running on it so that's not going to happen any time soon. Looks like it's time for me to move to Azure!
version of my database is 661.
when i attach my database in new version of sqlserver, version of my database changed to 665
Automatically.
I don't want to change version of my database.
how can i do that?
You can't prevent automatically database version upgrade when you're attaching/restoring database from lower to higher version of SQL Server.
Source: A lot of years of experience.
BUT, you can do a manual migration of higher version database into lower version by doing THIS
Well, I think you are using SQL Server 2008 R2 database which are 661 version. Hopefully you are trying to attach 2008 R2 to an SQL server 2008 instance but once the database has been upgraded to an 2008(665 version), it cannot be downgraded to SQL Server 2008 R2(661).
You need to uninstall SQL Express and reinstall the latest version to fix the problem.
You can't stop it changing the version, when an older version database is attached to a newer version of SQL server, it must perform these upgrade steps so before the database can be brought online on the new version. These upgrades are internal to SQL server and include things like file format changes etc, they themselves should not affect behaviour of your user code (although the changes in the new version of the SQL engine might).
The only significant result of these upgrade steps is that the database can no longer be attached or restored to an older version of SQL server.