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.
Related
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
I have created an SSIS project in Visual Studio 2019 containing multiple packages that upload Avro files to a AzureStorage connection type.
The project is targeting SQL2017, I have Azure Feature Pack installed on my machine version 2017 64bit.
This works ok on my machine but I am getting an error trying to deploy to SQL Server2017 to SSISDB Catalog:
Failed to deploy project. For more information, query the operation_messages view for the operation identifier '10'. (.Net SqlClient Data Provider)
Server Name: Datastore1
Error Number: 27203
Severity: 16
State: 1
Procedure: SSISDB.catalog.deploy_project
Line Number: 139
On the SQL server I did:
SELECT * FROM SSISDB.catalog.operation_messages
And could see this message:
Failed to deploy the project. Fix the problems and try again later.:Unable to create the type with the name 'AzureStorage'.
Installing Azure Feature Pack For SQL2017 has resolved my issue.
TITLE: Microsoft SQL Server 2012 Setup
The following error has occurred:
An error occurred during the installation of assembly 'Microsoft.VC80.ATL, version="8.0.50727.6229", publicKeyToken="1fc8b3b9a1e18e3b", processorArchitecture="x86",type="win32"'.
Please refer to Help and Support for more information.
HRESULT: 0x80070422.
The problem was with Windows update.The "Windows Module installer" service was disabled once i enabled it and cleared up all the updates in C:\Windows\software distribution folder, it started updating and when i install the sqlserver-2012 i dint get that error anymore.
This is where i found about the service.
https://answers.microsoft.com/en-us/windows/forum/all/windows-update-error-80070422/372f6482-ff7c-4f92-858c-228b637bfae4
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}
I have an SSIS package on Server2 (2008, 64 bit)and I am trying to call it from server1(2005, 32 bit) using xp_cmdshell using command,
exec xp_cmdshell 'dtexec /FILE "\\Wdvwd99a0234\PWOSSIS\RTS_SSIS\RTS_ETL.BE_2_DUNSMasterPackage.dtsx"'
It keeps giving error:
Microsoft (R) SQL Server Execute Package Utility Version 9.00.5000.00
for 32-bit Copyright (C) Microsoft Corp 1984-2005. All rights
reserved. NULL Started: 1:00:42 PM Error: 2012-11-29 13:00:42.83
Code: 0xC001700A Source: Description: The version number in
the package is not valid. The version number cannot be greater than
current version number. End Error Error: 2012-11-29 13:00:42.83
Code: 0xC0016020 Source: Description: Package migration from
version 3 to version 2 failed with error 0xC001700A "The version
number in the package is not valid. The version number cannot be
greater than current version number.". End Error Error: 2012-11-29
13:00:42.83 Code: 0xC0010018 Source: Description: Error
loading value "3" from node
"DTS:Property". End Error Could not load package
"\Wdvwd99a0234\PWOSSIS\RTS_SSIS\RTS_ETL.BE_2_DUNSMasterPackage.dtsx"
because of error 0xC0010014. Description: The package failed to load
due to error 0xC0010014 "One or more error occurred. There should be
more specific errors preceding this one that explains the details of
the errors. This message is used as a return value from functions that
encoun ter errors.". This occurs when CPackage::LoadFromXML fails.
Source: Started: 1:00:42 PM Finished: 1:00:42 PM Elapsed: 0.078
seconds NULL
As others have commented, the version of dtexec.exe needs to match the version of the target package. Your options are
Install the 2008 Integration Services components on Server1. You would need to provide an explicit path to the dtexec to ensure xp_cmdshell runs the 2008 version.
Run the package on the remote (Server2) machine. Lowest barrier of entry would be to create a SQL Agent job on Server2, unscheduled, that simply runs the package RTS_ETL.BE_2_DUNSMasterPackage.dtsx You would then start the job in place of the current xp_cmdshell. EXECUTE msdb.dbo.sp_start_job 'RTS_ETL.BE_2_DUNSMasterPackage' Two caveats to this approach
You can have as many concurrent dtexec calls running as your machine can support. A specific SQL Agent job cannot be running more than once.
If you were providing dynamic run-time options, that also isn't going to work with an agent job.
A 2008 package cannot be ran with the 2005 package utility.