I have built a custom job log framework which logs all of the tasks which are execute in an SSIS package along with any error that surface. Once complete, an enhancement was requested to also store any SQL queries that the SSIS package executes on the SQL Server. This is not limited to only Execute SQL tasks, they are looking for ANY SQL queries that the pack runs. I am aware of the OnInformation logging that is part of the SSIS logging framework, but this only shows some of the query.
Thanks in advance!
These is a free software on codeplex which I believe might satisfy your request at: https://sqlmetadata.codeplex.com/
If you need to code it, you should consider that there are two main types for deployed SSIS packages: Legacy mode and Catalog mode.
Legacy Mode deploys pacakges to msdb where you can find using SELECT name, packagedata FROM msdb.dbo.sysssispackages
Catalog Mode uses SSISDB, you can use catalog.get_project to return project_stream which represents a zip file containing the packages in the project. You can refer to How to export packages deployed in "Integration Services Catalog" using any command line, C# or T-SQL?.
After having the packages' XML, you can easily identify which components you want to export.
Related
I have an SSIS job that contains a script task.
There is also a connection to another server within the package that can only be executed accessed by a specific user and the agent cannot be given read rights to the other server.
So the solution to this is have the SQL job be run as the required user.
The problem with this is this user does not have full control over the folder/file where the script task will be temporarily located while the code runs so I get a failure on the script task but if I run it in visual studio or with the normal agent account the script task executes successfully.
I have tried giving the user access to all major drives on the server but this has not solved the problem
Is the script doing something on the folder?
Or does it just need permission to execute script?
I would anyway advise you to implement error handling in script:
https://learn.microsoft.com/en-us/sql/integration-services/extending-packages-scripting/task/logging-in-the-script-task?view=sql-server-2017
Make sure it works in visual studio, so that when you get that error you are sure that the error is caused by permissions/environment.
You could also take a look at this article:
article
I have the database table, stored procedures script, once the script file has pushed to TFS, the changes have to be deployed on the database
using azure devops.
How to setup SQL script file for build pipeline and release pipeline in Azure devops
thanks in advance,
Where you stuck exactly?
Add 'Azure SQL Database Deployment' task from market place to run sql script.
Choose 'Deploy type' accordingly.
#rAj is correct, when you add a new "Azure SQL Database Deployment' task to your agent Job, you can select to run an inline SQL script:
For Build pipeline
Add the SQL Server database deploy task
In Deploy SQL Using, choose Sql Query file.
In Sql File, you can specify the location of your Sql file.
For Release pipeline
The process is similar to build pipeline.
When i am trying to attach Analysis service db file (MDX Step-by-Step.abf)
by running the below commnand.
C:\Microsoft Press\MDX SBS\Setup\Analysis Services\Mdx Step-by-Step.abf
MDX Step-by-Step
IgnoreSecurity
I am getting below error.
Executing the query ... The following system error occurred: The
system cannot find the path specified. . Backup and restore errors:
File 'C:\Microsoft Press\MDX SBS\Setup\Analysis Services\Mdx
Step-by-Step.abf' specified in Restore command is damaged or is not an
AS backup file. Execution complete
This response/answer is for the users who land here while seeking solution to same kind of problems.
First issue mentioned in main post is related to path of '.abf'. It should be path on the machine, where Analysis Server is installed. Specially not on user's local machine, from where most of users connect through SQL Server Management Studio (SSMS) client application.
Second issue mentioned in comments is related to type of project. '.abf' extension is for tabular analysis services project rather than multi-dimensional data warehouse project. MDX queries are for multidimensional projects, whereas DAX queries are for tabular projects.
I have a 2008 SSIS package that have a lot of steps, one of the steps is a script task that runs a stored procedure. It is not an option for now to change it from a script task, as it would require a lot of extra developing. The procedure runs fine in the production environment, but I need to be able to test it from VS.
The reason for the failure I have found is that the connection to the target database is not working, it is giving error "Login failed for user 'user'".
The SSIS package is built on a SSIS framework, and it has a "Initialize Connections" task as an Event in the "Initialize" part of the package. I do not know much about what this does. I want to just run the Data Flow (With "Execute task" option inside the Data Flow).
In the ProtectionLevel for the package I have tried both DontSaveSensitive and EncryptSensitiveWithPassword without any luck. I manually insert the password in the Connection Manager.
I read some about the need to use a connection manager/XML file, but I'm unsure of how this can be done. (Not done much SSIS before).
Please explain how this debugging in VS should be done.
I created an SSIS package, which runs fine in Sql Server Business Intelligence. The problem is when I try to schedule a job to run, I tested it and it says the exe does not exist in the directory and it lists the path to the directory where the exe is located. The exe is obviously there, and the exe runs fine, it just doesn't like the package when I try to schedule a job.
The error that I can see in the job activity monitor is
Description: File/Process "FileName.exe" does not exist in the directory "DirectoryName" End Error
Anybody know how to fix this?
An SSIS package is not an EXE. The name is typically something like 'MyPackageName.dtsx'. The package is interpreted & executed by the DTS utility running in conjunction with a SQL Server instance.
We use SQL Agent to run SSIS packages as a standard part of our application, so that itself shouldn't be a problem. How do you have your SQL Agent job defined?