I am hoping that I can get some assistance with an error that I'm getting when trying to install the SQLServer2005_DTS.msi on Windows 10.
The error that I'm getting is:
'Module C:\Program Files\Microsoft SQL Server\80\Tools\Binn\dtsui.dll failed to register. HRESULT -2147024714. 'Contact your support personnel.'
I got the msi from
"Feature Pack for Microsoft SQL Server 2005 - February 2007" at https://www.microsoft.com/en-us/download/details.aspx?id=24793
It seems that the msi tries to to register the 4 dll's below but fails:
dtsui.dll
ctasksui.dll
cdwtskui.dll
sqlns.dll
I have also tried to manually register the dll's without any luck as follows:
Open a command prompt as admin
Change the directory to the Binn folder where the dll is located from the command prompt type cd C:\Program Files\Microsoft SQL Server\80\Tools\Binn
Register the dll, from the command prompt type: regsvr32 dtsui.dll
All I get is a return to the command prompt where I was expecting a dialog box.
SQL Server 2005 and some components are not compatible with Windows 10
https://technet.microsoft.com/en-us/library/ms143506(v=sql.90).aspx
What you can do it deploys a VM to use.
Its compatibility problem.Because its support till windows Vista.
Try to install in compatibility mode from properties option from run as administrator,
Related
I have an SSIS package that needs to run by a batch file. When I execute the SSIS package through SSDT it's working fine. But When I execute through "DTExec.exe" it's throwing below error message. I tried the deferent location of "
" but I was failed. What could be the reason?
After switching to the 64bit dtexec located in the 140 directory, I have an error indicating it cannot create a task from XML for task "Script Task"
Targets SQL Server 2017
The dtexec you'll find under IDE\CommonExtensions\Microsoft\SSIS\XXX\Binn\ where XXX is your version number is not for "regular" use. Those are for use with the Visual Studio/SSMS installation.
Instead, you're likely going to want one that is located in
C:\Program Files\Microsoft SQL Server\140\DTS\Binn\DTExec.exe
or
C:\Program Files (x86)\Microsoft SQL Server\140\DTS\Binn\DTExec.exe
depending on your 32 vs 64 bit requirements as well as the version of SQL Server you have installed (and have targeted your packages)
Your screenshot shows 150 but I don't see a 150 version of the dtexec installed on your machine but that could just be my eyes
I am trying to add a SQL Server Data Source to a Web Test in VS2017:
I click Install packages and get this:
Missing option value: installpath
How do I overcome this problem?
Edit 1:
Using Process Monitor I have identified the command VS2017 runs:
"C:\program files (x86)\microsoft visual studio\installer\vs_installer.exe" modify --focusedUi --installPath "" --activityId 6bb6d93d-8c2a-4462-9304-4ef2b29d27d1 --add Microsoft.VisualStudio.Component.SQL.DataSources --includeRecommended
The installPath is empty so I specified it as:
"C:\Program Files x86\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\"
When I specify the installPath I get this error:
System.ArgumentException: The directory path 'C:\Program Files x86\Microsoft Visual Studio\2017\Enterprise\Common7\IDE" --activityId 6bb6d93d-8c2a-4462-9304-4ef2b29d27d1 --add Microsoft.VisualStudio.Component.SQL.DataSources --includeRecommended' is invalid.
Parameter name: installationPath
I guessed since its trying to install a Package it must be:
"C:\Program Files x86\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PACKAGES"
That results in this error:
Unsupported option includeRecommended /finalizeinstall
What is the correct command?
Edit 2:
Confirming I already have the DataSources for SQ Server support installed:
Edit 3:
Ok, this is my fault.
I run Visual Studio using a shortcut that uses a junction to avoid the brackets in the path C:\Program Files (x86) in order to connect to an Oracle 9.2 database.
Running Visual Studio (not from the shortcut) I see the dialog and can connect to the Database.
However, when I click OK, no data source is added to the WebTest.
This is just a typical day using VS2017. I swear this product has not been properly tested.
So I ran a Process Monitor trace when I clicked the OK button in the Data Connection Dialog and I found one Access Denied:
Event Class: Registry
Operation: RegCreateKey
Result: ACCESS DENIED
Path: \REGISTRY\A\{A8BB3990-53C7-4BD7-A7E3-CFA0DD6BD4EC}\Software\Microsoft\VisualStudio\15.0_8708a912\Data Connection Dialog
TID: 11800
Duration: 0.0000764
Desired Access: Read/Write
I opened Visual Studios own Registry Hive (using these steps) and it turns out the Data Connection Dialog key didn't even exist. I created the Key, closed the registry, re-opened VS2017 and added a DataSource successfully:
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 was forced to upgrade my SSIS packages using VS2015 + SSDT, however I'm unable to get the compiled dtsx files to run now through command line using 130\DTS\Binn\DTExec.exe
Full error:
Source: Process file data flow SSIS.Pipeline
Description: To run a SSIS package outside of SQL Server Data Tools you must install Standard Edition of Integration Services or higher.
I've reinstalled MSSQL2014 w/ integration services and I see SQL Server Integration Services 12 is running.
DTExec.exe gets installed when you pick the "Integration Services" option off the setup CD. Make sure that it's installed in the directory indicated in the command line. You also need to make sure that the versions match between the SSIS package and DTEXec.exe. "..\120\DTS\Binn\DTExec.exe" is used for MSSQL2014.
I received this error from double-clicking a DTSX file which opened the Execute Package Utility from C:\Program Files\Microsoft SQL Server\140. I couldn't get it to work until I:
Saved off the command line from the "Command-line" tab of the utility
Navigated to C:\Program Files\Microsoft SQL Server\130\DTS\Binn
Called dtexec.exe with the command line
I think the Execute Package Utility was somehow looking for SQL Server 17 while I only had SQL 16 installed. DTExec.exe was able to find SQL 16 ok.
I have an SSIS package (created in VS 2013) that contains a C# 2012 Script Task.
The job of the script task is to download a file from an SFTP server using WinSCP .NET assembly and place it on my server (Windows Server 2012 R2 with SQL Server 2014)
My package runs fine when I run it on my Dev machine, but when I deploy to the server my package fails at this task with the error message
Exception has been thrown by the target of an invocation
I've done some digging and it looks like it has something to do with the reference to WinSCPnet.dll.
Quoting WinSCP article on Exception has been thrown by the target of an invocation:
This is just a high-level exception. The root cause is usually stored in the InnerException.
If you are getting this exception in SSIS, you can use try … catch block to capture the error, as show in the example for using WinSCP .NET Assembly from SSIS.
If you cannot access the inner exception easily, inspect WinSCP session log and debug log file (Session.SessionLogPath, Session.DebugLogPath). If those file are not even created, the root cause can be loading of WinSCPnet.dll assembly. See Could not load file or assembly ‘file:///…\WinSCPnet.dll’ or one of its dependencies. The system cannot find the file specified..
Installing the assembly to allow its loading is covered in Installing section of Using WinSCP .NET Assembly from SQL Server Integration Services (SSIS):
Installing
First, you need to install the WinSCP .NET assembly. Do not use the NuGet package.1
You also need to install the assembly to the GAC or subscribe AppDomain.AssemblyResolve event to allow loading the assembly.
The installation to GAC is covered by Installing to GAC section of Installation instructions for WinSCP .NET assembly:
Installing to GAC
In special cases, you may need to install the assembly into Global Assembly Cache (GAC), particularly to use it from SSIS.
When you install the assembly to GAC, you need to configure a path to WinSCP executable.
On Development Machine
To install the assembly into GAC on development machine, i.e. the one that has Windows SDK installed, use following command:
gacutil.exe /i WinSCPnet.dll
Windows SDK comes with Microsoft Visual Studio. You can also install it separately.
Use correct gacutil.exe for your version of .NET framework:
For .NET framework 4.0 or newer, use gacutil from Windows SDK 7.1 (or newer):
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1\bin\gacutil.exe;
For .NET framework 3.5, use gacutil from Windows SDK 6.0:
C:\Program Files (x86)\Microsoft SDKs\Windows\v6.0A\Bin\gacutil.exe
On Production or User's Machine
To install the assembly into GAC on production or user’s machine, you may install the assembly into GAC using:
Windows Installer, by creating .msi package;
Any other installer system that supports installing to GAC, e.g. Inno Setup;
System.EnterpriseServices.Internal.Publish.GacInstall method. PowerShell example:
Add-Type -AssemblyName "System.EnterpriseServices"
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("WinSCPnet.dll")
An absolute path to the DLL needs to be specified and Administrator privileges are required. Otherwise the above method will fail (and the only indication of the failure is sent to Windows Event log).
See How to fix NuGet WinSCP.NET in SSIS Script Task?
You need to install WinSCPnet.dll in the Global Assembly Cache for SSIS to pick up this dependency, see this blog for further details. You can install a DLL in the GAC using the following steps, see the documentation for further details:
Copy the WinSCPnet assembly to your local computer into a folder.
Start Visual Studio Command Prompt.
Type the following command: gacutil.exe /if ""
This installs the assembly to the GAC, overwriting any existing assembly that has the same assembly name.
If you have already registered the appropriate Dll's are are still getting this error, and you are passing in variables that are package-scoped, be sure to add them to the "ReadOnlyVariables" in the script task.
Right click on the task and click "Edit...", then click the "..." on the "ReadOnlyVariables" property, and add the variables that are referenced in your script.