I have moved my packages to another server. Now on that server when I am executing my packages on visual studio then it is working fine. But when I am deploying the same package and try to execute it both via integration services engine or SQL Job.. I am getting below error
An error occurred with the following error message: "Cannot bulk load. The file "C:\ABC\PQR\XYZ\myFile.txt" does not exist.".
Edit
Somehow that issue is resolved but now I am into one more issue
Packages installed in MSDB is working fine when I am clicking on Run Package. But when I am creating SQL Agent job for the same packages it is not working.
I have tried setting "rely on server encryption" but no luck :-(
I would suggest to check whether folder C:\ABC\PQR\XYZ\ have read permissions for an account used to run SQL Agent jobs.
If this is **C:\ABC\PQR\XYZ** mapped drive connection then use the UNC path it worked fine through the server agent.
Related
I'm having issues running a .dtsx package made in Visual Studio 2019.
In Visual Studio when using "Start without debugging" it runs perfectly with no errors, however when I try to launch the file from command line it's giving me a non-descript error and terminates the package.
It runs for some time and does execute a few of the tasks at the start of the package, however it does not get very far.
This is the "error" showing in the command prompt:
Message: <DTS:ProcessMemoryUsage xmlns:DTS="www.microsoft.com/SqlServer/Dts">DTS:PeakWorkingSetSize177860608</DTS:PeakWorkingSetSize></DTS:ProcessMemoryUsage>
When I look at the error dump, this is what I see:
This is my execution command
"C:\Program Files\Microsoft SQL Server\130\DTS\Binn\DTExec.exe" /f "C:\**PATH**\Visual Studio 2019\Projects\DataDropPrep\DataDropPrep\MSX DataDrop.dtsx" /conf "C:\**PATH**\Visual Studio 2019\Projects\DataDropPrep\Test.dtsConfig" /DECRYPT "****" /CONSOLELOG /DumpOnError /REPORTING EW
I don't understand why it works perfectly when run within Visual Studio 2019 but not in the commandline.
The package is set with target server 2016 (To match our SQL server).
I'm running the package from a local VM on my own PC, but the SQL server is deployed in Azure (cloudapp.azure.com).
I am NOT a DB admin, so I can't add the package to be run from the SQL Server itself unfortunately, wish that I could, would make my life a lot easier.
Alas I am stuck manually running this package every day from my own PC, and I'm trying to automate it with a .bat file, so I need this command working.
This is the package layout, it first truncates a staging table, then loads all items modified or created in the past 3 days, then deletes matching rows in the production table, then imports the new rows from staging. Repeat for all the different objects:
When using "Start without debugging" from Visual Studio 2019, it executes without issues:
Turns out the issue was that I was using a project parameter, which works when running from Visual Studio, but not when executing the dtsx file directly.
After converting the parameters from project to package, it executes successfully!
Without the logging and the insights that provided I wouldn't have known where to start.
Success
In the same folder as the package, SSIS generated a file SQLDUMPER_ERRORLOG.log. This pointed to a file in C:\Program Files\Microsoft SQL Server\150\Shared\ErrorDumps. This folder contains text files such as SQLDmpr0085.mdmp. When I click on this, it launches Visual Studio and gives an error message "The thread tried to read from or write to a virtual address for which it does not have the appropriate access."
After hours of experimenting and doing web searches, I discovered that I was not passing the correct package name to dtexec.exe. Once I corrected this, I was able to execute packages with no issues.
I create a new package in SSIS and when I try to run the package, SSIS returns the following error (displayed in a Visual Studio Error Dialog):
"Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration"
Environment: VS 2019 with newest SSIS Extension Installed. The package appears to be created correctly and the build succeeds.
The error happens even if the package is trivial "hello world" type of package.
I found no solution to this after a fairly extensive search.
Thanks to EmersioN (https://stackoverflow.com/users/707267/emersion) for the solution. The problem in this case was the selected targeted version of SQL Server. My project was configured to target "SQL Server 2017", but was connected to a server running SQL Server 2012.
If you're seeing this error, this may be the reason.
Go to the properties page of the Integration Services project that contains the affected package. In the Property Pages dialog, navigate to Configuration Properties > General. Under the property group, Deployment Target Version, in the TargetServerVersion property drop-down, select the SQL Server version that matches the one you're connected to.
I just came across this as well in VS2019 SSDT. In my case it was a working SSIS package that after going to sleep for the night, the machine woke up and wouldn't execute the same scripts. These were my steps. Hope they help you or someone else who stumbles across this.
Open each connection within the script, Test Connection and Save
Clean the solution
Rebuild the solution
My context
Working through an SSIS tutorial using SQL Server 2019 Developer (v15.0.2080.9) and VS2019 Community (v16.11.9) to create packages using SSDT (SSIS Projects v3.15).
Packages in VS have executed without issue in the past. I then upgraded my machine from Windows 10 Pro to 11. Now, when running the same - possibly any - package I get the following error:
===================================
Failed to start project (Microsoft Visual Studio)
===================================
Cannot create a debug host for the package. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.LaunchVsDebugger(Boolean isRemoteTest, IVsDebugger iVsDebugger, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsPackageDebugger.ValidateAndRunDebugger(Int32 flags, IOutputWindow outputWindow, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, ProjectItem startupProjItem, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchActivePackage(Int32 launchOptions)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.LaunchDtsPackage(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
at Microsoft.DataTransformationServices.Project.DataTransformationsProjectDebugger.Launch(Int32 launchOptions, DataTransformationsProjectConfigurationOptions options)
===================================
Cannot communicate with the debug host process. The IDtsHost interface is not registered. (Microsoft.DataTransformationServices.VsIntegration)
------------------------------
Program Location:
at Microsoft.DataTransformationServices.Project.DebugEngine.DebugEngine.LaunchDtsDebugHost(Process& process, Boolean run64bit)
at Microsoft.DataTransformationServices.Project.DebugEngine.DtsProgramNode.CreateRuntimePackageInternal(IDtsHost& host, Process& process, Package& dtsPackage)
...and the package does not execute.
What was tried
I tried/checked all 3 answers posted here.
Error persists.
This VS Dev Community's post recommended upgrading the VS extension, SSIS Projects. Since I had the most recent version installed an upgrade was not applicable, so I chose the repair option from the installer.
Error persists.
I then ran a repair on the VS2019 install. This, in turn, required another repair on SSIS Projects. (I still had both installers on my machine which made this easy.)
Error persists.
This MSDN post recommended re-registering DtsDebugHost.exe, failing that, re-installing SQL Server.
I ran the DtsDebugHost.exe /regserver command.
Error persists.
My Solution
I then chose to repair my SQL Server installation instead of re-installing. This was accomplished via the SQL Server Installation Center > Maintenance > Repair option. In my case, I chose the default instance, MSSQLSERVER.
VS now runs without the error and successfully executes the package.
I couldn't say whether my solution was solely based on the repaired SQL Server instance or a combination of other things tried and my last action. So I offer the path I took in the case of the latter.
Aside: The other choices during the SQL Server repair on my system were (1) another server instance, SQLSERVER2019, and (2) "shared components". Selecting either of those may have resolved the issue as well, but I couldn't confirm that.
In Project Property, turn off Azure-Enabled as seen in the image below. Your package will execute afterwards.
I encountered this error after upgrading to Windows 11.
I referred to the post by #steveb and went straight to his solution of repairing SQL Server (SQL Server Installation Center > Maintenance > Repair), without doing any of the other steps he tried.
And that solution worked.
I'm posting this because #steveb said he was unsure if any of his previous steps had affected the ultimate solution, and in my experience they were not necessarily needed.
I am writing a tool that allows a DBA to remotely run an SSIS package. The application is an XBAP and has been deployed to a SQL Server, with the SSIS package on the same server. I achieve the remote calling of the SSIS package by running DTExec remotely on the server (I open the servers DTExec utility, not a local version) running as another user using Process.Start.
Here is the issue that I'm getting. When running the application (from the server) from my desktop it works absolutely fine. DTExec is started and the SSIS package is executed. However, when I go to a different computer within our same network, I receive the error
The application was unable to start correctly (0xc0000143). Click OK to close the application.
This has happened on multiple computers, but for some reason works from mine.
The only difference between the two computers, is that mine has a version of SQL Server developer on it (meaning I have a local DTExec tool - however I am not calling this tool, the path is to \\server\Microsoft SQL Server...\DTExec.exe).
Does anyone have any idea what's going on here?
Found the answer via this blog post: http://asprosys.blogspot.ca/2009/03/perils-and-pitfalls-of-launching.html
Adding Credentials to the Process.StartInfo requires have permissions on the local machine as well as the server where the application is running and where the application you are attempting to run is found.
Using Microsoft's Release Management Server for Team Foundation Server 2013 v12.0.31101.0, I keep getting an error (included later). I can however successfully run the sqlpackage command from my local machine, the build server and the target SQL Server.
Steps taken:
I took the dll's and the sqlpackage.exe from C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin and copied them to a folder on my desktop
In Release Management, I created a new Tool with the command: sqlpackage.exe /Action:Publish /SourceFile:__FileName__ /TargetDatabaseName:__DatabaseName__ /TargetServerName:__ServerName__
I then added the dll's and the SqlPackage.exe from the folder I created a step earlier
Save and Close
I then created a new component which basically just wraps this tool (The Build Drop Location is a backslash to indicate the dacpac is at the root of the build folder)
I then selected the Tool I created and it filled in everything. I updated my release template to include and use the component
Putting the folder I created on any desktop, I can run the following command and it run just perfectly
sqlpackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /TargetDatabaseName:MyDatabase /TargetServerName:MyDatabaseServer
I did this from my local PC, the Build Server and the SQL Server itself, but when I use Release Management, I get the error.
Error:
An unexpected failure occurred: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception..
Unhandled Exception: System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacPackage' threw an exception. ---> System.TypeInitializationException: The type initializer for 'Microsoft.SqlServer.Dac.DacServices' threw an exception. ---> System.TypeInitializationException: The type initializer for 'SqlSchemaModelStaticState' threw an exception. ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.SqlServer.TransactSql.ScriptDom, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
Update 1: I noticed on the error email from Release Management that the Target Server was my web server and not the SQL Server, even though the SQL Server was correctly named in the command. I checked the log on the web server and found the errors. I copied over my folder of dlls to the desktop and ran the script and voila, I was able to recreate the error. I checked the installed programs in Control Panel and noticed that the installed version of Transact-SQL ScriptDom was for 2012, version 11.0.2100.60. So I installed SSDT here. The installation failed because I don't have Visual Studio installed, but it still managed to install the 12.0.2000.8 versions of Transact-SQL ScriptDom and related dlls. When I ran the script again, it successfully published the database! However, when I tried to build from Release Management, I got a new error.
Publishing to database 'Logging' on server 'BYDWVCMNSQ01'.
Initializing deployment (Start)
Initializing deployment (Failed)
*** Could not deploy package.
Unable to connect to target server.
Update 2: So, I've confirmed the reason it was failing at this point was because the account that the build server was using did not have a login account to the SQL Server. I added the account and then granted it ddladmin and securityadmin privileges at the database I'm targeting. This yields a new error that I'm unable to create a new user, but at least I'm getting closer.
Final Update: I had to also grant sysadmin so the account could create a login. This allowed the deployment step in RM to succeed. This obviously is not the way I will leave it, I'll either use a publish profile or command flags to prevent the dacpac from being created with security objects and let it run with least privilege.
The issue of getting RM to deploy to SQL 2014 has been solved. The main issue was in my release template, I placed the DACPAC component inline with the rest of the build for my web server. This causes the DACPAC command to be run from the web server, and for that to work I had to install SSDT on the web server. I don't like this, and I'll probably rearrange my release template so that the web server and sql server are parallel, but nested under the same rollback.
On the server running the deploy, run procmon with a filter for the missing dll, then copy it into one of the folders it is looking in.
The correct way would be to install ssdt and the scriptdom bits (search for creating a headless ssdt build machine)
I had luck with this answer, switching from the old "SqlPackage" to the new one, I think it's some sort of confusion of related dll's:
To fix this issue, change the path to sqlpackage.exe to the new '140' version. The new path to sqlpackage.exe should be:
"%ProgramFiles(x86)%\Microsoft Visual Studio
14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140\SqlPackage.exe"
On our new server, when I try to run the SSIS packages from Integration Services in SSMS (ie by right clicking on the package and selecting "run")
I get the following error
The program has failed to Load the library "c:\Program Files\Microsoft SQL Server\100\DTS\Binn\dts.dll"
Odd - the dll file is at that address, the SQLAgent login (under which integration services and Sql Agent runs) has permission to execute the file, and I have permission to execute the file (meaning we both have full control on the folder containing the dll). I can't see any reason why integration services wouldn't be able to load the library
This happens with all packages on the server
Stopping and restarting services (SQL and SSIS) has not resolved the issue
Any ideas?