I have a report that calls a proc to load a list of Ids (procLoadIds) and then a proc that gets all my data (procGetData).
I start a SQL profiler trace with the RPC:Completed, RPC:Starting, SQL:BatchCompleted, and SQL:BatchStarting events and nothing filtered. I then refresh the page my report is on, choose my parameters, and click "View Report". I expect I should see a call to procLoadIds and procGetData in the trace results somewhere but I don't... is there something I'm missing setting up this trace?
I seem to be having issues when I am passing a lot of Ids so I want to see the actual "execute procGetData" with the parameters being passed so I can run that manually in SSMS.
UPDATE: I started seeing this show up but only for the event RPC:Completed. is there a way I can see this when I call it (I thought that's what RPC:Starting might do), not after it finished (or more specifically timed out).
Related
I have a shiny app that runs a monte carlo simulation with 500 replications. To do this, I use a for loop and call a function from another package to run the simulation, and then I save the data. The shiny app then produces the results using renderTable.
It is possible that the user could mistakenly enter something that would cause one or more of the replications to fail to converge, triggering a stop in the function I'm calling. If this happens, there is nothing to render in a table. In R, I get a nice error message from the package telling me that the model failed to converge. However, in Shiny, the app just force closes.
I'm currently using tryCatch and showNotification to display this notification in the app (see below):
observeEvent(input$go,
tryCatch({
simulation_results()
},
error = function(err){
showNotification(paste0(err), type = 'err')
})
)
It works well, but the problem is that it causes the app to take 6x longer to run (it goes from ~1.5 min to ~10 min). I think this is because it's trying to catch and show the notification from every individual replication in the for loop. The app also still does close; it just displays the error first (which I do appreciate).
Is there a [faster] way to get shiny to print error messages from the console instead of closing the app?
I was thinking of validate, but I don't know how it would work - what I really need is something like
validate(need("no error message in the console")). I tried using validate(need(simulation_results(),geterrmessage()) to see if it would simply print the last error message if there were no simulation results, but the app shuts down once it gets to the stop error in the function.
Also, I'm using flexdashboard if that changes anything.
I have a SSIS package which contain 5 sequence task container and inside that other control flow task. all are running parallel.
i am trying to have all audit and metadata information like package name,task name and current status of task (running,completed or failed.)
The Bigger Problem i feel here is how to handle once the status of the task got changed.
this information i am trying to save in sql table
package name i can get from system variable, how to get current status of Task.
i am trying to store status value like "start","in-progress","end".
May someone please share your thoughts.
Thanks
You can capture the change of a task's state by using SSIS's Event Handlers. To do this, click on the task itself and then click on the Event Handlers tab at the top of the design-time window. This will bring up a blank window with a blue link in the middle of the page as follows:
Before you click on the blue link, select a specific Event Handler that you want to handle:
From here, you can execute specific tasks. For example, you can run an SMTP mail task in the OnError Event Handler to send an e-mail alert regarding a task error. Or, you can run an Execute SQL Task in the OnPostExecute Event Handler to send data to the database once a task has completed.
I think for your specific problem (how to get Run Time for a task), you will need two Event Handlers:
OnPreExecute: Capture the system's datetime value via GETDATE() and write it to a SQL table as SequenceContainerTaskNameStartTs
OnPostExecute: Capture the system's datetime value via GETDATE() and write it to a SQL table as SequenceContainerTaskNameEndTs
Where 'Ts' stands for TimeStamp.
You can then calculate the runtime with the DATEDIFF() function and specify the time interval (e.g., seconds, minutes, hours, etc.). This value can either be stored in a separate field on the table (i.e., SequenceContainerRunTime) or simply generated on-the-fly in a SQL SELECT.
For more information on SSIS's Event Handlers, read here:
Integration Services (SSIS) Event Handlers
I am currently implementing Send Email notification on error in my SSIS package. It currently works. Just want to check if this is the right way of doing it.
If you want to trigger your mail task when any error occurs, consider the "Event Handlers".
This SimpleTask article provides a very good overview of the event handlers
https://www.red-gate.com/simple-talk/sql/ssis/ssis-event-handlers-basics/
SSIS event handlers are the simplest means of turning an SSIS script into a reliable system that is auditable, reacts appropriately to error conditions, reports progress and allows instrumentation and monitoring your SSIS packages. They are easy to implement, and provide a great deal of flexibility.
Sample screen shot:
Using event handler provides some advantage - you need not connect each task's failure. The system will call your event handler for the error.
Also, note there are 2 event handlers of interest:
OnError
OnTaskFailed
https://learn.microsoft.com/en-us/sql/integration-services/integration-services-ssis-event-handlers
OnError event - This event is raised when an error occurs.
OnTaskFailed event - This event is raised by a task when it fails.
One thing to watch out for is that you event handler may be called multiple times depending on the number of errors.
I think there is no standard answer to this question. But here are some of the tips that I am be able to think of.
First, not very sure what kind of plain text you are trying to send out, if they do not have dynamic text body, you could put that send email task in the event handlers right to the Control flow, Data Flow... tab, and put that on error for specific tasks.
Second, I personally do not prefer to use Failure output, you may need to increase the number of MaximumErrorCount so that the package could executed successfully, but sometimes the real error might not be detected because together with error output, the total error numbers is still less than the threshold.
Third, if you are sending the same text, and you will schedule it as a job in SQL Server Agent, you could go to Notifications option page, set the Send Email, basically it will be informative.
Last but not least, the Send Mail task supports plain text only, not any formatting like email coded by html & CSS, if you need to take the formatting into consideration, that might not be your choice, you could use Script task using C# or creating html page by using XML statement from your SSMS and put into a stored procedure, then sent out the html by Database Mail, you will find this tool under Management folder in your SSMS.
I have written a script to update my db table after reading data from db tables and solr. I am using asyn.waterfall module. The problem is that the script is not getting exited after successful completion of all operations. I have used db connection pool also thinking that may be creating the script to wait infinitly.
I want to put this script in crontab and if it will not exit properly it would be creating a hell lot of instances unnecessarily.
I just went through this issue.
The problem with just using process.exit() is that the program I am working on was creating handles, but never destroying them.
It was processing a directory and putting data into orientdb.
so some of the things that I have come to learn is that database connections need to be closed before getting rid of the reference. And that process.exit() does not solve all cases.
When my project processed 2,000 files. It would get down to about 500 left, and the extra handles would have filled up the available working memory. Which means it would not be able to continue. Therefore never reaching the process.exit at the end.
On the other hand, if you close the items that are requesting the app to stay open, you can solve the problem at its source.
The two "Undocumented Functions" that I was able to use, were
process._getActiveHandles();
process._getActiveRequests();
I am not sure what other functions will help with debugging these types of issues, but these ones were amazing.
They return an array, and you can determine a lot about what is going on in your process by using these methods.
You have to tell it when you're done, by calling
process.exit();
More specifically, you'll want to call this in the callback from async.waterfall() (the second argument to that function). At that point, all your asynchronous code has executed, and your script should be ready to exit.
EDIT: As pointed out by #Aaron below, this likely has to do with something like a database connection being active, and not allowing the node process to end.
You can use the node module why-is-node-running:
Run npm install -D why-is-node-running
Add import * as log from 'why-is-node-running'; in your code
When you expect your program to exit, add a log statement:
afterAll(async () => {
await app.close();
log();
})
This will print a list of open handles with a stacktrace to find out where they originated:
There are 5 handle(s) keeping the process running
# Timeout
/home/maf/dev/node_modules/why-is-node-running/example.js:6 - setInterval(function () {}, 1000)
/home/maf/dev/node_modules/why-is-node-running/example.js:10 - createServer()
# TCPSERVERWRAP
/home/maf/dev/node_modules/why-is-node-running/example.js:7 - server.listen(0)
/home/maf/dev/node_modules/why-is-node-running/example.js:10 - createServer()
We can quit the execution by using:
connection.destroy();
If you use Visual Studio code, you can attach to an already running Node script directly from it.
First, run the Debug: Attached to Node Process command:
When you invoke the command, VS Code will prompt you which Node.js process to attach to:
Your terminal should display this message:
Debugger listening on ws://127.0.0.1:9229/<...>
For help, see: https://nodejs.org/en/docs/inspector
Debugger attached.
Then, inside your debug console, you can use the code from The Lazy Coder’s answer:
process._getActiveHandles();
process._getActiveRequests();
I am using ssis event handler to trigger an email whenever an error occured in the entire package(PACKAGE+ONEEROR). Here number of emails triggered is equal to number of errors generated.How can I restrict it to one mail eventhough the same error occured 10 times.
Please suggest....
You have a few options. The problem with setting an ONERROR email at the package level is that it will send an email for each error the package encounters. This gets ugly if you have a deep level transform fail, which will error as it fails back up to the package level.
I suggest that you either:
1) Setup ONERROR events at the task level and remove the package level event. Usually this will be good enough. Most tasks will only have one error to report. Be careful with Data Flows, they can act in a similar fashion as the package level events.
2) Setup some sort of advance logging. I’ve seen this done several ways. I’ve seen some people setup Script tasks to log the errors (at the task level) to a variable, and then send a final email containing the variable in the body (at control flow level). I have also seen people call stored procedures (at the task level and package level) for each error that occurs. The sproc would log errors to the DB and allow the package to continue on to the next step/container. The logged errors can then be dumped into a csv and emailed as an attachment.
If you like your current setup, you can try changing the error properties for each container/task. I haven't ever done this, but I do know you can change the way tasks handle errors! I don't like this option because you would possibly be missing errors (maybe? kind of guessing).
update From another solution - If you want to keep your current email ONERROR and simply prevent certain errors from "bubbling" up and sending emails, you can follow this link to learn how to gracefully handle errors. You could prevent certain tasks errors from reaching your ONERROR event at the package level. good luck.