I am working as part of a wider team, on an SSIS package. We use TFS for collaboration, and the package has links to .sql files amongst other things.
When I run the package manually, the package runs without any issues, as the connection manager references my directory. When someone else tries to execute the package, they get an error message "Could not find a part of the path ......... script.sql"
Is there a way to correctly reference the TFS location, so it works for everyone, or is there some other way to reference these files in SSIS, so they work for everyone in the team?
Thank you
Related
I must put this program into production today, and I can't get it to run independently.
In the program, I have included NuGet package "Imports ClosedXML.Excel" and use it to create spreadsheets. When I build my executable, and try to run it from another computer, it cannot find the ClosedXML and Documentformat.OpenXml assemblies.
I checked in References that "Copy Local" was = True for ClosedXML and Documentformat.OpenXml, but it's not working. I found another website that mentioned Global Assembly Cache, and that if the dependency is in there, it will not be included in the Build .exe.
I am running Visual Studio Professional 2017. I am in over my head on this one, so if you have answer (and I hope you do), please try to provide it in elementary terms I can understand.
Sometimes issue is solved by individually adding application files inside the following menu
Go to Publish-->Application Files
Select Show all files
Under Publish Status
Set the files you need to Include [not include(auto)]
I'm trying to use VSTS to deploy into my database, the problem is in one of the steps I need to pick up the dacpac file and deploy it to the Azure SQL server but it fails:
in that step, I'm using "Execute Azure SQL: DacpacTask" which is provided by Microsoft in VSTS.
there is a filed to do it which is called "DACPAC File" and the documentation said to use it like this:
$(agent.releaseDirectory)\AdventureWorksLT.dacpac
but it gave me the below error:
No files were found to deploy with search pattern
d:\a\1\s\$(agent.releaseDirectory)\AdventureWorksLT.dacpac
so I did a cheating and put the below value in it:
d:\a\1\s\AdventureWorksLT.dacpac
it does work but obviously, it won't work forever as I need to use an environment variable, something like :
$(agent.releaseDirectory)\AdventureWorksLT.dacpac
any suggestion?
I've had this same problem. I wasn't able to find detailed documentation, but from experimenting, this is what I found.
I'm assuming that your DACPAC is created as part of a Build Solution task. After the build completes and the DACPAC is created, it exists in a sub-folder of the $(System.DefaultWorkingDirectory) directory.
Apparently, the Azure SQL Database Deployment task cannot access the $(System.DefaultWorkingDirectory) folder. So the file must be copied somewhere where it can be accessed. So here's what I did:
The Visual Studio Build task builds the solution, including the DACPAC. The resulting DACPAC is placed in a $(System.DefaultWorkingDirectory) sub-folder.
Add a Copy Files task as your next step. The Source Folder property should be "$(System.DefaultWorkingDirectory)". The Contents property should be "**/YourDacPacFilename.dacpac". The Target folder should be $(build.artifactstagingdirectory). The "**/" tells VSTS to search all subfolders for matching file(s).
Add an Azure SQL Database Deployment task to deploy the actual DACPAC. The DACPAC file will be in the $(build.artifactstagingdirectory).
I had the same problem and I solved it by removing the old artifact from the release and adding it again to take the correct alias of the new artifact.
That's why the Azure SQL Database Deployment task says it doesn't have access to the $(System.DefaultWorkingDirectory) folder, the artifact has changed and you must make sure you're using the new one that is saved in the azure pipeline.
I've got a .dacpac file that's being called by MSBuild and published to a QA database for testing. This publish is failing and the error I'm getting back from them is a generic "an error has occurred" message. I was hoping I could generate the deployment script from the dacpac and walk through it to see where the problem is occurring and hopefully teach them how to do this as well.
Is there any way to point a dacpac at a specific database and have it generate the sql for updating the database without actually publishing to the database?
You can use SqlPackage.exe. Look for it on your machine in a directory with a name similar to this:
C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin
Note that it may be found in the 110, 120 or 130 folder.
If you don't have SqlPackage.exe already, you can download it from here: https://www.microsoft.com/en-us/download/details.aspx?id=53013
If you download it, be sure to look in the System Requirements section of the download page to find the dependencies SqlSysClrTypes.msi and SqlDom.msi, which must be installed as well.
Example usage:
SqlPackage.exe /a:script /SourceFile:C:\temp\mydb.dacpac /TargetConnectionString:"Data Source=myserver;Initial Catalog=mydb;Integrated Security=true" /OutputPath:C:\temp
I have an SSIS package named Extract.dtsx. I want to deploy it to the file system in F:\SQL2005\MSSQL\Package\Extract.
The Package Instllation Wizard does this simply. I only have to choose "File system deployment" and choose the path, then click next a few times and finish. I'm having trouble figuring out if I can do the same this using DTUTIL.
Does anybody know if this is possible?
Yes, it's possible. I'm not sure what I was doing wrong.
If you have an SSIS package C:\temp\Extract.dtsx, you can deploy it to the file system in F:\SQL2005\MSSQL\Package\Extract using these commands:
c:\temp\md F:\sql2005\mssql\package\Extract
c:\temp\dtutil /file Extract.dtsx /Copy FILE;F:\sql2005\mssql\package\Extract\Extract.dtsx
The destination folder must already exist.
You can see the package in SQL Enterprise Manager by connecting to SSIS on the server, open Stored Packages > SSIS Application Packages > Extract.
I have a SSIS master package, which executes several child packages. It works great, but when I deploy it to the file system on the server, I get an error code "0xC00220DE". "The system cannot find the file specified."
When I run the package on the server by double-clicking it, it works correctly. But when I use DTExec:
dtexec /FILE "d:\cmcdx\ssis\MAESTRO_FACTURACION.dtsx"
I get the mentioned error.
The package configuration is correct, and the user I'm executing the package with is administrator of the machine.
Should I deploy the packages to Sql Server? What are the best practices for deploying a master-child package? I'm running out of ideas here...
By the way, I'm running Sql Server 2005 sp3.
Solved it.
I was using relative paths to point to the child packages, and in runtime SSIS was unable to find them.
In the end I used a specific path, set in a configuration file. Then I used the deployment utility, copied everything to the server, run it by double clicking on the SSISDeploymentManifest file and changed the paths to the proper location.
Thank James and Justin for your answers.
Is the package not getting a path or location value from a package configuration file? If so make sure you include the /ConfigFile argument and the path to the config file. Another thing to possibly check is if you have any connections in the package that refer to mapped network drives, these may not work running under the different service account than your local console account.
[Edit]
Try this command line below on the server (notice the double slashes).
dtexec /FILE "d:\\cmcdx\\ssis\\MAESTRO_FACTURACION.dtsx"
There are several things that could be going wrong here. You mention that you're using a master package to run several child packages. Are all of your child packages in their proper location on the server as well?
Remember that the paths to the child packages should be variables in your master package so that those values can be changed through a configuration file on the server if need be.
You might also want to check out this set of tutorials on MSDN:
Package Deployment How-To Topics
These tutorials explain how to properly enable package configurations on the server when your package runs.