I am running SSIS packages on SQL Server 2016 and am trying to log events using Dts.Events.FireInformation and Dts.Events.FireWarning. While these do show in the local IDE progress section, they are not appearing in the SSISDB Logs (e.g. R-Click on a package / Select Reports / All Execution). I also tried Dts.Log() but that didn't write either. I've used logging in the past (circa 2008R2) to the old ssis logging table. I know I can use that but would rather keep these all in oneplace.
Logging level is "Basic" which should pump out both OnInformation and OnWarning.
I did look at this post on StackOverFlow which looks like it had a viable answer; however, the link to that answer is dead.
Is this just not possible to do or am I doing something wrong?
When the packages run in Visual Studio, the Information and Warning events are logged to both the Package Results tab as well as the Output window.
That data only gets recorded into the SSISDB if the server is the one running the packages.
Related
Using a SQL Server Agent job to start a SQL Server Integration Services Pachage step.....
In the package itself, is there a way to pick the path of the package that was started?
I want to pick up the "folder" info of where the package resided that is executing, to help build some variables.
TIA,
Doug
This works for me .
Viewing the List of Running Packages
You can view the list of packages that are currently running on the server in the Active Operations dialog box. For more information, see Active Operations Dialog Box.
For information about the other methods that you can use to view the list of running packages, see the following topics.
Transact-SQL access
To view the list of packages that are running on the server, query the view, catalog. executions (SSISDB Database) for packages that have a status of 2.
Programmatic access through the managed API
See the N: Microsoft.SqlServer.Management.IntegrationServices namespace and its classes.
Use the Active Operations dialog box to view the status of currently running Integration Services operations on the Integration Services server, such as deployment, validation, and package execution. This data is stored in the SSISDB catalog.
Open the Active Operations Dialog Box
Open SQL ServerManagement Studio.
Connect Microsoft SQL Server Database Engine In Object Explorer,
expand the Integration Services node, right-click SSISDB, and then click Active Operations.
https://msdn.microsoft.com/en-us/library/hh213131(v=sql.120).aspx
Will my package run successfully by using SQL Server Agent if I have data viewers enabled and breakpoint? I'm using SQL Server 2008 - SSIS.
Breakpoints and Data Viewers are only artifacts that have meaning within the debugger. If running your package from SQL Agent fails, then there's a whole host of things that could be wrong, generally permission related, but a data viewer or a breakpoint will not be one of them.
No. Breakpoints and data viewers will not be a hinderance. Your package should run successfully if there are no other errors.
In This Scenario ,Answer is NO.
When create a breakpoints then we have to press next of F5 for proceed the package .
In case of data viewer there is prompt for check OK so ultimately job get failed .
I've deployed a SSIS package to my SQL server.
I can run the package fine by connecting to Integration Services in SSMS and right clicking on it and choosing "Run Package"
However, if I schedule the package, it fails.
It tells me to check the logs for information on why, but there is nothing in there...
Any ideas?
(this is my first SSIS package by the way)
I would guess your package is doing something the SQl Server agent deosn't have the rights to do. Often it turns out that the location of file to be imported or the location where the file exported are in directories that are not open to the account that runs the SQL Server Agent.
I also agree woth Raj who said you really need to implement logging. You can;t expect to know why something fails six months down the road if you aren't recording the details of waht is happening with the package. SSIS pacakages can be hard to debug anyway, so you need those logs to know where to start looking.
You have to implement logging to get the details of the error.
In SQL Server Agent, create a new job, configure it to execute the package and under the logging tab, start logging.
Then run the package and you can read the log in the job history.
When you said you have scheduled a job, I assume you used SQL agent. In that case you can right click job and click View History and you can see the error related to job not to the package. For detail error you need to configure logging.
We set up SQL server in a cluster. We then used one of the BizTalk servers and installed SSIS on it. We then configured BAM. Everything looked fine until we needed to run some of the SSIS jobs to archive stuff. They don't seem to have been created ...
We then tried to change the value in the MsDtsSrvr.ini.xml file and restart the SSIS on the BizTalk server and tested again but still no luck.
What do we need to do and where do we need to change the value in the MsDtsSrvr.ini.xml file?
In this post Richard S. discusses problem but I can still can't seem to get it to work ...
Difficult to say exactly what the problem is based on your comment.
Couple of things you could check:
Is your sql server database installed on a named instance?
What rights does the account that you used to run the install have?
In my development environment, every time I reboot windows (which must be done at least daily for me), all of my Shared SSRS Datasources lose their credentials.
Currently I have them set up to log into the database using a fixed credential, but on reboot all the datasources pop over to using no credentials. Granted, it's only in the dev environment, and I can just check out/update the datasource/check back in and it will work fine... until I reboot again.
FYI, I've been using these Shared Datasources for at least 2 years and no problems, but in the last month or so, it's been a recurring daily problem.
Help?
I'm assuming you are talking about the Shared Data Sources in a Report Server project in Visual Studio, as opposed to a Data Source created directly on Reporting Services. The latter, the data is stored all in the ReportServer database that was specified when setting up SSRS.
Now, as for the .rds file used in Visual Studio, if you open the file up in a text editor, notice that the username and password is not stored in the file. It is actually stored in the .rptproj.user file. So, check that someone didn't remove the .user file from source control (.user files shouldn't be in source control, but in your case...).
This is scenario is testable by entering your credentials, saving all files, and exiting Visual Studio. Find and delete the .rptproj.user file, and open your Report Server project up again and see the credentials gone!
A work around is add the "User ID=user;Password=pass" as part of the Connection String. When the .rds is opened up, the Connection String won't show this portion, but the Credentials tab should have the right values.
Could this be related to the boot order of services on your machine.
Just a guess: Maybe there is new functionality in SP3 that checks if the connection credentials are valid. If they are not valid they are cleared.
The problem would then happen if this check is done before SQL server has had time to start. This would explain why they are cleared when the machine restarts.
I have recently experienced the same problem, but I can't connect it to a reboot. It seemed to happen when I checked the solution from source control - we use Team Foundation Server. After disabling the service account a bazillion times, it somehow healed itself and began behaving. I found this post and checked my project folder for the rptproj.user file that benson mentioned, and it has a modified date of the day I had problems, but a create date of close to what I can remember as having created the project, so I will pay attention to this in the future.
Did anyone come up with anything new on this issue?
I realize you may have read this already, but something here could help? http://msdn.microsoft.com/en-us/library/ms159846.aspx
I would pay attention to how the SSRS was installed and also what accounts the servies run as, as well as an domain logon policies.