I have created a SSIS package for migrating data from one sql server database to another. The tasks are created in a sequence container.
I have created events in the event handler and added the send mail task for sending email and getting the following error. I get this error even when I try to evaluate the expression in the expression builder. Please note that I am getting the error on the onTaskFailed event handler. I think the system error variables are not accessible in that event. Do I really need that event handler
I can see the variable in the collection. Not sure of how the scope affects it.
This is definitely a scoping issue. The system variable 'ErrorDescription' is only avialable at 'OnError' event handler and can't be used in 'TaskFailed' event handler. As to the question of if you need it or not, that is something your business logic should dictate. I would suggest to move your code to 'OnError' event handler.
Related
Using SSIs 2016 trying to set an input parameter to a sql task to System::ErrorDescription, but that variable isnt listed. Is this variable not used any longer?
I have sql task that, if it fails, I want to log the error desciption to a table. Yes, I know I can enable logging, but I want also use this message in another task.
[Edit]
I think this variable is only visible within the context of an event handler such as OnError, correct?
The System::ErrorDescription variable is not available for all components, specifically it is only in the OnError, OnInformation, and OnWarning event handlers.
https://learn.microsoft.com/en-us/sql/integration-services/system-variables?view=sql-server-2016
Is it possible to throw an exception in a Logic App?
Specifically, I'm trying to throw an exception inside of a scope. Then in the run after of the scope I'd check if it failed and inspect it for errors. I tried using a terminate inside of a scope, but that terminates the entire logic app run.
As an updated solution we can use Terminate control, Terminate control has 3 status: Failed, Canceled, and Succeeded.
Quick Answer (TL;DR)
Problem: MSFT Azure logic app throwing exceptions
Workaround: Use logic app Scope element to simulate throwing exceptions
Create a scope element to use as your "try-catch" block
Force the scope element to fail with an invalid command to simulate an exception
Allow the scope element to fail naturally and that will count as an exception too
Detailed Answer
Context
MSFT Azure logic app workflows
live version as of 2020-06-14
Problem
Scenario: Developer wishes to throw an exception or use try-catch semantics in a logic app
Solution
As of this writing, the live version of the product does not support this feature. There is a workaround.
Workaround
Use logic app scope element
add a conditional statement inside the scope element
If the conditional statement meets the failure condition, force an exception with a deliberately invalid command
for example create a variable assignment with the value int('__ERROR__')
If the conditional statement does not meet the failure condition, do nothing
The rest of the logic app consists of two paths
The first path runs on the success of the scope element
The second path runs on the failure of the scope element (failed, skipped, timed out)
Example
Create a scope element as a "try-catch" block
Create a variable compose element with an invalid command
int('__ERROR__') ## this will cause the enclosing scope to fail
## the string __ERROR__ cannot be cast to integer
Respond to exit status of the Scope element enclosing your exception
See also
related SO answer about forcing exceptions https://stackoverflow.com/a/61101945/42223
No, there is no Action or Connector directly analogous to something like a throw in C#.
The closest you can get right now would be to do something like use another LogicApp instead of a scope from which you can return a specific status code.
It seems like there still is no option for this inside Logic App or its little brother Power Automate / Microsoft Flow.
The way I have come up with and have used in some flows, is I simply add an action for something I know for a fact will fail.
The simplest (and probably the cheapest as the built-in actions cost less in Logic Apps, even if we are talking fractions of a dollar here either way) is probably to initialize a variable, e.g. called ThrowException with type of integer.
Then a "Set variable" action is added wherever I want my flow to fail, where I set the value (remember it is of type integer) to any string expression. I simply use the expression string('Exception').
Simple example screenshot
Since the value is set via an expression this is still a valid template, but will fail upon runtime when the value is actually being set.
After this, simply use parallel branches, with appropriate Run After settings, as usual.
Is it possible to raise built-in MS Access form events programmatically? I have a
feeling it isn't but thought I would check. (I am using Access 2003).
For instance, I want to do something like this within a private sub on the
form:
RaiseEvent Delete(Cancel)
and have it trigger the Access.Form delete event -- i.e. without actually
deleting a bound record.
Note my delete event is not handled by the form itself but by an external
class, so I can't simply call Form_Delete(Cancel).
I can understand your confusion -- I didn't explain any of the bigger context. Sorry.
Basically, the situation is I have an 'index' i.e. 'continuous-forms' form which is bound to a read-only query. The query has to be read only because it involves an outer join. But, I want to be able to delete underlying records from this form.
So my first thought was to do the deletion outside the form recordset, eg. using a delete query. And I was hoping to hook the standard Delete/BeforeDelConfirm/AfterDelConfirm events around this manual deletion routine by raising these events myself. But alas, this is not possible.
If the form itself handled these events, I could simply call the handlers (Form_Delete, etc), but my project has custom classes that handle form delete and update events (validation, confirmation, logging, etc.) for all the forms. (#Smandoli, it's not well-documented, I just discovered it a few months ago and use it extensively now -- maybe you know about it already -- you can set up external classes to handle your form events. See for example here)
Long story short, I found a workaround I'm satisfied with. It involves making the 'index' form a subform of another form that is bound to a recordset that can be deleted from. So the deletion can be done in the outer form using the standard Access form events, based on the selection in the inner form.
#Knox, I disagree in principle that being able to raise 'built-in' events yourself is difficult to document and maintain. Plenty of other frameworks depend on it. In practice, I agree with you, since we all have to work within the limitations of our tools and 'best practices' that evolve around those limitations. The blessing and curse of Access is its tight binding between recordsets and forms...
In common, there is simply no need to fire standard form events on your own, normally this shows a wrong understanding of form events in general (if not even events in general).
The form events exists to react on user interaction with the form or to notify the code behind of something that generally happens (like the Form_Load event). The event subs are there to react on these event - nothing more.
It is an often seen thing that people wants to execute event subs directly, but that's also a wrong way. There is a reason why event subs are in general declared as "Private" and not "Public", it should prevent calling them directly from outside the code module, but in fact you should also not execute any of them inside the same code module. Event subs always has to be called exclusively by their events, although it's possible to call them directly.
If an event sub has any code which should be executed also elsewhere then create a private or public sub inside the same module (depending on if you want to execute them from outside or not) and then call this sub from the event sub. If you think you must execute the same sub from elsewhere you can now also call the same sub. This is not a question of "it is possible to call the event sub directly", it is mainly a design question. You should always be sure that an event sub was called only by the event itself and never by any code. The problem when calling an event sub by code is that you can get in trouble very fast if you execute a code and also a real event executes it. In the end you get a big chaos of code which is very hard to debug.
It is, by the way, of course possible to call the event subs from a class module which has a reference to the form (which is needed if you use the class module to handle general events). You only would need to declare the event subs as Public and then you can call them with the form reference, but as stated above: Don't do that.
If a class module is used to handle the events then you can do anything here, you don't need the form code.
If a query is read only and you want to delete a record of a base table no event sub could help you. They are fired when the user wants to delete something which he can't do because it's read only so DoCmd does also not help you.
Like David said in the comment above, simply create a Delete button anywhere you want which can then read out the ID of the current row in the continous form and start a "DELETE" SQL command, then simply requery the continous form and you're done. You can also handle this in your standard class module because you can not only forward form events you can also forward control events on the same way. Create an Init procedure in your class module which takes all the controls from your form you want to handle with it any maybe additional the name of the base table in each continous form, then the class module can assign it to a standard "WithEvents" defined control variable of for example type CommandButton and save the base table name to a string variable. (Don't forget to set the OnClick event to "[Event Procedure]" in the Init procedure.)
In the Load event of your continous form where you probably initialize your class module you can then forward the base table name and the delete button control to the Init procedure of the class module which then can handle the deletion on a very generic way by starting a DELETE query on the base table and requery the form because it already has the form reference also. No need to call any event procedure.
Last but not least: Maybe there are frameworks which allow you to raise events directly but in common I would say that the creators of such frameworks also didn't understand the purpose of event procedures. If you have ever created an own event in a class module of your own you will see that they also cannot be raised outside the class module. Of course, you CAN create a "RaiseEvent" sub on your own to call them externally - and in fact, in case of own events it can make sense in some scenarios. In case of form (control...) events they should inform the code about something happened and there should be a reaction now. If you use events in own class modules you would normally also create a "WithEvents" variable in the outside module to get informed when an event happened in the other class module. An event should make it possible to make the module objects independent of each other. The module with the event will only raise the event and it doesn't know if anyone is listening to it or react on this event. It informs "the world" that there was something which happened in the class module, nothing else. Like a radio station which sends the daily news "to the world" but it doesn't know about if anyone listens to it. Normally, no listener of the radio station would go to the radio station and reads his own news for other listeners. Only the people at the radio station decides what to send and when. Same story.
I need to log the Severity of Error in OnErrorCode event handler in SSIS.
Severity can be like : Info, Warning, Critical
I am just curious if anybody knows about how to get this information to log in EventHandler in SSIS and provide any URL which can be useful in looking for this ?
Just to clarify, are you referring to something that is internal to SSIS, or is this some bespoke classification?
In SSIS, there is an OnInformation event and OnWarning event in the same manner that there is an OnError event. Maybe you could consider logging out from these events as well as the OnError event.
As far as I can tell, only OnError will fail your package, unless there is something I am missing.
While I'm developing my MS Access application, I open it with shift click. When an Error occurs, that is not trapped (by ON ERROR ...), a message box pops up informing me about the error. This is a good thing.
When a user open my application, he does't shift click, and an appropriate Start Form opens. However, now untrapped Errors don't show up, the application behaves as if the user clicked the Stop Button on the message box. I don't want this behaviour.
Is there an option / property / variable that provides the same behaviour in the production code (preferably even when the application id converted to an mde) as in development, i.e. show a message box for every untrapped error? Or is it neccessary to trap errors in every single event routine and pop up a message box by program?
It turns out, this is a side effect of setting the AllowSpecialKeys property to False. This can be done programmatically, but I did it in the menu under Tools > StartUp.
Since this property allows the user to open the code editor, it kind of makes sense, but the relationship of the phenomen described to this option was puzzling for me.
Does this mean, that if I want to hide my code, I need to write all those error handlers? Or is there one central place (like a main method in Java) where I can invoke an error handler. Alternatively, could I allow specical keys and just protect the code with a keyword?
You can create your own error handler and add it to all procs, subs and functions. You have this very nice MZ Tools VBA add-on that allows you many thing such as adding line numbers to your code, "preprogramming" your error label, etc.
If you are smart enough, you'll be able to use this add-on to generate a standard "error management" code displaying things such as err.number, err.description, and the undocument erl value, which is the number of the line where the error occured (you must first have your lines numbered before being able to get this value).
EDIT: I just opened this question on a similar subject.
As alluded to, MZ-Tools 3.0 is a great tool to aid in quickly adding error handlers. Also remember that errors which occur in procedures without error handlers "bubble up" to the last-invoked On Error statement. (And if no statement exists you get the little gray debug box.) The net effect of this, is that you can do minimal error handling by simply adding error handlers only to those procedures which are Public (or Friend) or called by event. This will make sure you always have at least 1 "top level" error handler invoked. If you want to add special handling to your private procedures after that feel free. If not, when an error occurs in them they will "bubble up" to the top level error handler.