What version of Integration Services do we roll? - sql-server

I've been handed a SQL Server 2019 which should have CU15 installed. It has Integration Services installed and we use it for running SSIS jobs.
Looking at the assemblies on the disk we see a lot of this file version
2019.150.2000.5
So, I went over to this nice web page KB4518398 - SQL Server 2019 build versions and looking into the different file versions on specific assemblies.
Specifically I can see that we have a crash in odbcdest.dll and so I've concluded the the file version of this file (located in D:\Program Files\Microsoft SQL Server\150\DTS\PipelineComponents\ which is the 64-bit compiled version of that assembly) is also
2019.150.2000.5
which at least is logical.
But looking at the page from Microsoft referred in this question there have been a lot of updates in the different CU:s from the release of the RTM version. I've put together this list of all changes to odbcdest.dll from that page:
RTM/CU Date Version Size Link
------ ----- ------- ---- -------
RTM 2019-11-04 2019.150.2000.5
CU01 2020-01-07 2019.150.4003.23 376424 https://support.microsoft.com/en-us/topic/kb4527376-cumulative-update-1-for-sql-server-2019-a8dae09e-96b5-9f13-9092-977341fafe17
CU02 2020-02-03 2019.150.4013.40 369752 https://support.microsoft.com/en-us/topic/kb4536075-cumulative-update-2-for-sql-server-2019-1c344add-96bd-0810-433e-f7f9326c393c#file
CU03 2020-03-12 2019.150.4023.6 369544 https://support.microsoft.com/en-us/topic/kb4538853-cumulative-update-3-for-sql-server-2019-04829099-2b9f-863b-c8c1-aa82306a1ff4
CU04 2020-03-14 2019.150.4033.1 369752 https://support.microsoft.com/en-us/topic/kb4548597-cumulative-update-4-for-sql-server-2019-4b7b7c3f-0f14-3a9a-185c-3f973dabfe52
CU05 2020-06-10 2019.150.4043.16 316296 https://support.microsoft.com/en-us/topic/kb4552255-cumulative-update-5-for-sql-server-2019-084c602b-dc4a-d599-c857-5f18cec950fa
CU06 2020-07-25 2019.150.4053.23 316304 https://support.microsoft.com/en-us/topic/kb4563110-cumulative-update-6-for-sql-server-2019-757cb0fa-56ff-c6e4-d56b-a695b7fdc64e
CU07 2020-08-15 2019.150.4063.15 369552 https://support.microsoft.com/en-us/topic/kb4570012-cumulative-update-7-for-sql-server-2019-87ea390d-0def-6173-efd2-f6be8549d77d#bkmk_13585628
CU08 2020-09-13 2019.150.4073.23 316296 https://support.microsoft.com/en-us/topic/kb4577194-cumulative-update-8-for-sql-server-2019-ed7f79d9-a3f0-a5c2-0bef-d0b7961d2d72
CU09 2021-01-25 2019.150.4102.2 369552 https://support.microsoft.com/en-us/topic/kb5000642-cumulative-update-9-for-sql-server-2019-97ad5c3e-e002-4b6d-b566-698bf70ca44a#bkmk_13607161
CU10 2021-03-25 2019.150.4123.1 316304 https://support.microsoft.com/en-us/topic/kb5001090-cumulative-update-10-for-sql-server-2019-b6b696ec-6598-48d9-80ee-f1b85d7a508b
CU11 2021-05-27 2019.150.4138.2 316296 https://support.microsoft.com/en-us/topic/kb5003249-cumulative-update-11-for-sql-server-2019-657b2977-a0f1-4e1f-8b93-8c2ca8b6bef5
CU12 2021-07-19 2019.150.4153.1 316296 https://support.microsoft.com/en-us/topic/kb5004524-cumulative-update-12-for-sql-server-2019-45b2d82a-c7d0-4eb8-aa17-d4bad4059987
CU13 2021-09-23 2019.150.4178.1 369552 https://support.microsoft.com/en-us/topic/kb5005679-cumulative-update-13-for-sql-server-2019-5c1be850-460a-4be4-a569-fe11f0adc535#bkmk_13981081
CU14 2021-11-03 2019.150.4188.2 316320 https://support.microsoft.com/en-us/topic/kb5007182-cumulative-update-14-for-sql-server-2019-67b00a61-4f30-4a36-a5db-b506c47e563b#bkmk_14253624
CU15 2022-01-22 2019.150.4198.2 369544 https://support.microsoft.com/en-us/topic/kb5008996-cumulative-update-15-for-sql-server-2019-4b6a8ee9-1c61-482d-914f-36e429901fb6
CU16 2022-04-11 2019.150.4223.1 317352 https://support.microsoft.com/en-us/topic/kb5011644-cumulative-update-16-for-sql-server-2019-74377be1-4340-4445-93a7-ff843d346896
So, obviously Microsoft has done some working during the time from the RTM release.
Now, to my question.
If CU15 was installed why is the file version of this assembly still reporting the file version of the RTM?
It seems to me that that assembly has not been updated att all despite that CU15 should have been installed.
If we install CU16 would that upgrade Integration Services files? I would then expect 2019.150.4223.1 as the file version of odbcdest.dll
Below are an error from the event log that seems to indicate a real problem.
Fault bucket 1530726703783532086, type 5
Event Name: SQLException64
Response: Not available
Cab Id: 0
Problem signature:
P1: ISServerExec.exe
P2: 0.0.0.0
P3: 0000000000000000
P4: OdbcDest.dll
P5: 2019.150.2000.5
P6: 000000005D8A80CE
P7: -1073741819
P8: 000000000001C8EB
P9: 0000000000000000
P10:
Attached files:
\\?\C:\Program Files\Microsoft SQL Server\150\Shared\ErrorDumps\ISServer_2774_92f5b77a-8b53-4703-ae89-d252652ca787_0.mdmp
\\?\C:\Program Files\Microsoft SQL Server\150\Shared\ErrorDumps\ISServer_2774_92f5b77a-8b53-4703-ae89-d252652ca787_0.mdmp
\\?\C:\Program Files\Microsoft SQL Server\150\Shared\ErrorDumps\ISServer_2774_92f5b77a-8b53-4703-ae89-d252652ca787_0.tmp
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER5DF5.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER5E15.tmp.xml
These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\Critical_ISServerExec.exe_182514701e9ac3cc1cb72270426a8a84197f3757_00000000_1051626a
Analysis symbol:
Rechecking for solution: 0
Report Id: 008c56b8-4633-42b4-8fb1-22555163e580
Report Status: 2147487744
Hashed bucket: 1a4563239b9578ef153e3bd3b338d636
Cab Guid: 0

If I wanted to know what version/patch level of SQL Server, I'd run the following query
SELECT SERVERPROPERTY('ProductVersion') AS ProductVersion, ##VERSION AS MyVersion;
15.0.4223.1
Microsoft SQL Server 2019 (RTM-CU16) (KB5011644) - 15.0.4223.1 (X64) Apr 11 2022 16:24:07 Copyright (C) 2019 Microsoft Corporation Express Edition (64-bit) on Windows 10 Enterprise 10.0 (Build 19044: ) (Hypervisor)
The assembly reflects that patch level.
I don't have an unpatched machine handy, but I think you'd have to explicitly not upgrade your SSIS componentry

Related

installation on SQL Server 2019 Developer fails

I downloaded the file SQL2019-SSEI-Dev.exe and ran it.
I chosed media-download as well as user-defined. In both cases I got the same result.
I chosed german and english. In both cases I got the same result.
The installation-package could be downloaded without problems.
Then when it starts the installation assistent I got this message box.
I installed SQL Server Express before without problems. Before the installation of the Developer-Edition I deinstalled the Express.
I tried it several times but I am out of ideas now.
Windows Version:
net framework version:
C:\Windows\Microsoft.NET\Framework\v4.0.30319>msbuild -version
Microsoft (R)-Buildmodul, Version 4.8.4084.0
[Microsoft .NET Framework, Version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten.
4.8.4084.0
C:\Windows\Microsoft.NET\Framework\v4.0.30319>

Could not load file or assembly 'Microsoft.AnalysisServices.AdomdClientUI'

SQL Server version: SQL Server 2016 SP2 GDR 2019 (KB4505220) -
13.0.5101.9 (x64) Issue: Analysis Services Processing Task: Error: Could not load file or assembly
'Microsoft.AnalysisServices.AdomdClientUI, Version=13.0.0.0,
Culture=neutral, PublicKey Token=89845dcd8080cc91' or one of its
dependencies. The system cannot find the file specified.
Actions Made so far:
Follow the option 3 assembly binding from this site. Got this error after: Analysis Service Processing Task: Error: Method not found: 'Boolean Microsoft.analysisServices.AdomdClientUI.AdomdConnectionStringBuilder.IsAzure()'
Install CU2 but during install it states that current SP2-GDR is latest
Any idea on the fix?
We were able to fix the missing dll file when patching to SQL 2016 SP2 version 13.0.5622.0 (CU11 + Security Update) Release Date Feb 25, 2020.

Cannot succesfully install TimescaleDB on Postgres 10 (Windows Server 2016)

I am having trouble getting TimescaleDB to work on my windows server 2016 machine with Postgres 10.
I open up a fresh windows server 2016 instance with AWS and I install Postgres using the windows GUI installer. (C:\Postgres).
The installer automatically updates the path to include the bin directory (C:\PostgreSQL\pg10\bin).
I stop postgres.
I run the TimescaleDB windows installer file and it says it's successfully completed.
I update the conf file. (shared_preload_libraries = 'timescaledb').
I restart my computer and start postgres, but postgres never sucessfully starts. The windows event yells at me, saying I 2018-03-29 17:01:35 UTC [952]: [1-1] user=,db=,app=,client= FATAL: could not load library "C:/POSTGR~1/pg10/../pg10/lib/postgresql/timescaledb.dll": The specified module could not be found.
Any idea whats going on?
This may be related to https://github.com/timescale/timescaledb/issues/485#issuecomment-377533298 which is caused by a missing dependency, Visual C++ Redistributable for Visual Studio 2015.

Error Running SSIS Package from Command Line

Ultimately, I'm trying to schedule SSIS packages to run on a regular basis using Task Scheduler in an Azure VM (Windows Server 2016 Datacenter). From the command line on my development machine (Windows 10), I'm able to run...
dtexec.exe /Project "pathToMy.ispac" /Package "pathToMy.dtsx"
...and it works as expected. However, when I try to do the same from the Azure VM I get the following error:
Microsoft (R) SQL Server Execute Package Utility Version 11.0.6020.0
for 32-bit Copyright (C) Microsoft Corporation. All rights reserved.
Started: 2:17:46 PM Could not load package
"MyPackage.dtsx" because of error 0x80131500.
Description: The package failed to load due to error 0xC0011008 "Error
loading from XML. No further detailed error information can be
specified for this problem because no Events object was passed where
detailed error information can be stored.". This occurs when
CPackage::LoadFromXML fails. Source: MyPackage
Started: 2:17:46 PM Finished: 2:17:47 PM Elapsed: 0.547 seconds
On both machines, I have the same version of SQL Server 2016 Developer (w/ SSIS) and Visual Studio 2015 installed. Also, I'm able to run the package fine on the VM from within Visual Studio. It's only from dtexec.exe that I have issues.
I've tried every solution on here from other posts getting similar errors and none have helped. Any ideas?
Thanks,
Ian
Thanks to #Nick.McDermaid, the answer to this riddle has been found. By running dtexec.exe (with no parameters) on the dev machine and on the VM, I was able to see that the VM version was v11 and the dev version was v13 which explained why I was getting the error and why one worked and another didn't.
I then did a File Explorer search on the VM for dtexec.exe copies and found several. Apparently, the environment path was set to find the older version. I probably could have found the variable causing this problem and changed it. However, out of concern about breaking something else and wanting a quick solution, I chose to execute using the full path to the correct version. For v13, this ended up being...
"C:\Program Files\Microsoft SQL Server\130\DTS\Binn\dtexec.exe"
So, for my schedule task I set the following properties for my "Start a program" action.
Program/Script: "C:\Program Files\Microsoft SQL Server\130\DTS\Binn\dtexec.exe"
Add Arguments: /Project "bin/Development/myProject.ispac" /Package "myPackage.dtsx"
Start in: c:{path to my .dtsx file}

SSIS 2016 / Visual Studio 2015 Deployment Issues

I am running into an issue with SSIS project deployment using Visual Studio 2015 and SSIS 2016 [SSISDT March 2016 update] (SQL Server 2016 13.0.1300.275).
I am receiving the following error, when clicking deploy on the project or package:
Field not found:
'Microsoft.SqlServer.IntegrationServices.Wizard.Common.Model.DeploymentModel.TargetServerVersion'.
I originally assumed it was due to the fact that the project was upgraded from a previous version of SSIS, so I created a new project altogether specifically for 2016, but received the same error.
The error doesn't appear to be coming from the SQL Server itself, instead from Visual Studio 2015 and the SQLDT.
I am hoping someone else may have encountered this issue and may have a suggestion on how to proceed.
Folder capture after the build.
Output of Build:
------ Build started: Project: 340BHierarchyReDesign_Migration, Configuration: Development ------ Build started: SQL Server
Integration Services project: Incremental ... Starting project
consistency check ... Project consistency check completed. The project
is consistent. File 'C:\Users\kjackson\Documents\TFS Project
Repository\SSIS Projects
2016\340BHierarchyReDesign_Migration\340BHierarchyReDesign_Migration\obj\Development\340BHierarchyReDesign_Migration.dtproj'
get updated. 340BHierarchyReDesign_Migration ->
C:\Users\kjackson\Documents\TFS Project Repository\SSIS Projects
2016\340BHierarchyReDesign_Migration\340BHierarchyReDesign_Migration\bin\Development\340BHierarchyReDesign_Migration.ispac
Build complete -- 0 errors, 0 warnings
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========
This is a known issue with SQL 2016 and Visual Studio 2015 with SSDT, as of RC1 and RC2. There are apparently assemblies in SSDT and 2016 RC1\RC2 that are mismatched at this time and as a result you are unable to debug or deploy anything from the Visual Studio 2015 environment.
The current suggested workaround from Microsoft is to either uninstall SSDT and SQL 2016 RC1\RC2 from the computer running Visual Studio 2015 and reinstall the SSDT only. Or install an early release of the SSDT which limits you from using the 2016 features. This maybe resolved in RC3.

Resources