Showing posts with label trigger. Show all posts
Showing posts with label trigger. Show all posts

Wednesday, March 28, 2012

Packege success, despite task failure

Hello,

When I run my package, a task will fail, however, the package will claim that it was successful. Why is this, and how can I trigger a failed package when one task fails?

Thanks in advance.

Look at your package execution properties. You will see the "Fail package on Failure" option. The package claiming that it is successful is odd. You might want to also look at the "Maximum Error Count" property (again at the package level) to make sure you haven't set it higher than 1. Look at the "Force Execution Result" property also to make sure you don't have it set to "successful".

Hope this helps.

|||

Where do I find 'Maximum Error Count' and 'Force Execution Result'?

|||They are properties of the package (and of the control flow tasks and containers). If you click in an empty area on the control flow of the package, and hit F4, you should see the properties window.

Packege success, despite task failure

Hello,

When I run my package, a task will fail, however, the package will claim that it was successful. Why is this, and how can I trigger a failed package when one task fails?

Thanks in advance.

Look at your package execution properties. You will see the "Fail package on Failure" option. The package claiming that it is successful is odd. You might want to also look at the "Maximum Error Count" property (again at the package level) to make sure you haven't set it higher than 1. Look at the "Force Execution Result" property also to make sure you don't have it set to "successful".

Hope this helps.

|||

Where do I find 'Maximum Error Count' and 'Force Execution Result'?

|||They are properties of the package (and of the control flow tasks and containers). If you click in an empty area on the control flow of the package, and hit F4, you should see the properties window.

Saturday, February 25, 2012

Over-ride a trigger

I have a table which, until now had an update trigger only.
That trigger was used to record the record as it existed BEFORE the change,
and who made the change. It works fine.
Now I have a situation where a program will INSERT a row into the table
(which now has a new field). The value of the field is calculated. I have
two choices,
1) Re-write a lot of code to calculate the value before the insert
2) Write a simple insert trigger to calculate the value and update it in
the table.
Problem:
If I use the insert trigger to update the value, I am doing an update. The
update trigger will fire. I do not want the update trigger to fire when this
operation is performed.
Is there a way I can add code to the Insert trigger to tell it that when it
updates the value it should prevent the update trigger from firing'
Thanks.Roger,
If the value is calculated:
Can you use a calculated column?
Can you calculate the value in the select statement?
AMB
"Roger Twomey" wrote:

> I have a table which, until now had an update trigger only.
> That trigger was used to record the record as it existed BEFORE the change
,
> and who made the change. It works fine.
> Now I have a situation where a program will INSERT a row into the table
> (which now has a new field). The value of the field is calculated. I have
> two choices,
> 1) Re-write a lot of code to calculate the value before the insert
> 2) Write a simple insert trigger to calculate the value and update it i
n
> the table.
> Problem:
> If I use the insert trigger to update the value, I am doing an update. The
> update trigger will fire. I do not want the update trigger to fire when th
is
> operation is performed.
> Is there a way I can add code to the Insert trigger to tell it that when i
t
> updates the value it should prevent the update trigger from firing'
> Thanks.
>
>|||We cannot use a calculated column as the values must not change and the
values used to calculate can change over time.
We are currently using select statements that calculate but the process is
labourious and complex so we are trying to force consistent data with lower
cpu utilization (One insert is read many many times)
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:B0B63AC0-5557-4C66-83DE-BBFC526E8C44@.microsoft.com...
> Roger,
> If the value is calculated:
> Can you use a calculated column?
> Can you calculate the value in the select statement?
>
> AMB
> "Roger Twomey" wrote:
>|||Roger,
If I understood, you calculate the value during the insert but you want it
to be static after it is done?, In this case you can stop the update trigger
.
...
if update(calculated_column) return
...
If you do not use bulk insert, then I would recommend to insert the row
using a stored procedure. If as you said, the calculation is labourious and
complex, doing it in a trigger will make the transaction longer and will
impact the performance of the engine and scalability of the db.
AMB
"Roger Twomey" wrote:

> We cannot use a calculated column as the values must not change and the
> values used to calculate can change over time.
> We are currently using select statements that calculate but the process is
> labourious and complex so we are trying to force consistent data with lowe
r
> cpu utilization (One insert is read many many times)
> "Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in messag
e
> news:B0B63AC0-5557-4C66-83DE-BBFC526E8C44@.microsoft.com...
>
>|||That is true, but the impact will only occur on insert, not on every read.
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:3CF33806-F33D-433E-8305-0450AF8E938B@.microsoft.com...
> Roger,
> If I understood, you calculate the value during the insert but you want it
> to be static after it is done?, In this case you can stop the update
> trigger.
> ...
> if update(calculated_column) return
> ...
> If you do not use bulk insert, then I would recommend to insert the row
> using a stored procedure. If as you said, the calculation is labourious
> and
> complex, doing it in a trigger will make the transaction longer and will
> impact the performance of the engine and scalability of the db.
>
> AMB
> "Roger Twomey" wrote:
>|||Thanks for the tip (If update(calculated_column) return)
I think that should work.
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:3CF33806-F33D-433E-8305-0450AF8E938B@.microsoft.com...
> Roger,
> If I understood, you calculate the value during the insert but you want it
> to be static after it is done?, In this case you can stop the update
> trigger.
> ...
> if update(calculated_column) return
> ...
> If you do not use bulk insert, then I would recommend to insert the row
> using a stored procedure. If as you said, the calculation is labourious
> and
> complex, doing it in a trigger will make the transaction longer and will
> impact the performance of the engine and scalability of the db.
>
> AMB
> "Roger Twomey" wrote:
>|||On Mon, 28 Feb 2005 13:07:46 -0500, Roger Twomey wrote:

>Thanks for the tip (If update(calculated_column) return)
>I think that should work.
Hi Roger,
That will only work if the calculated_column is never updated from other
sources than the insert trigger.
Other options to investigate are:
* Check if it's possible to disable nested triggers (note: this can only
be done at the server level; it will affect all databases on the
server).
* Checking the value of TRIGGER_NESTLEVEL() (or maybe even the value of
TRIGGER_NESTLEVEL(object_ID('upd_trigger
'))).
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

Overlapping Trigger Precedence

Hi,
What is the execution precedence if there exist more than one update, delete
or insert triggers
I mean if there are more than one type of trigger such as more than one
update trigger.
Also, Can we specify a precedence for them?
and last If we call an update statement in the same update trigger and for
the same table that has this trigger, Is the trigger considers itself, I
mean is it recurs or not, or is it disables itself for that execution period
?.
Thanks in advance...
Emre GuldoganThere is no guarantee as to what order they'll fire in.
Adam Machanic
SQL Server MVP
http://www.sqljunkies.com/weblog/amachanic
--
"Emre Guldogan" <ask me please...> wrote in message
news:e$KbhKMJFHA.656@.TK2MSFTNGP14.phx.gbl...
> Hi,
> What is the execution precedence if there exist more than one update,
delete
> or insert triggers
> I mean if there are more than one type of trigger such as more than one
> update trigger.
> Also, Can we specify a precedence for them?
> and last If we call an update statement in the same update trigger and for
> the same table that has this trigger, Is the trigger considers itself, I
> mean is it recurs or not, or is it disables itself for that execution
period
> ?.
> Thanks in advance...
> Emre Guldogan
>|||You can use sp_settriggerorder to define the first and last trigger to
execute. For the rest the order is undefined. If it matters to you then
put all the logic in one trigger.
David Portas
SQL Server MVP
--|||On Wed, 9 Mar 2005 18:11:48 +0200, "Emre Guldogan" <ask me please...>
wrote:

>What is the execution precedence if there exist more than one update, delet
e
>or insert triggers
>I mean if there are more than one type of trigger such as more than one
>update trigger.
>Also, Can we specify a precedence for them?
Hi Emre,
Already addressed by David and Adam.

>and last If we call an update statement in the same update trigger and for
>the same table that has this trigger, Is the trigger considers itself, I
>mean is it recurs or not, or is it disables itself for that execution perio
d
>?.
There are two options governing this:
1. Recursive triggers. If this is off, a trigger can't fire itself. So
if an update trigger on table AA performans an UPDATE AA command, that
specific trigger is not called. This disables only direct recursion: if
the update trigger on AA performs a DELETE FROM BB statement, and the
delete trigger on BB performs UPDATE AA, the trigger will be called
recursively.
The recursive triggers option is a database setting: it will affect all
triggers in the current database, but it won't affect other databases on
the same server. You use ALTER DATABASE to change it.
2. Nested triggers. If this is off, statements executed from a trigger
don't fire any trigger at all.
The nested triggers option is a server setting: it will affect all
triggers in all databases on the server. You use sp_configure to change
it.
Other options to prevent recursive execution of triggers for specific
triggers only are:
* TRIGGER_NESTLEVEL() - check this to find how many nested trigger
executions there currently are.
* TRGIGER_NESTLEVEL(object_ID('trigger_nam
e')) - check this to find how
many times the specified trigger is currently nested.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)