We are currently having the following process finger-pointing  issue...

Assume you have the following situation...

An Orders table
A Shipments table
An Invoice table

A separate program takes Orders information and Inserts rows into the
Shipments table (at time of shipping)

When rows are inserted into the Shipments table via "the Shiping Process", a
trigger "for Invoicing" is fired.

Currently, it appears that some random rows are "missing" from the Shipment
table after the shipping process occurs.

There are at least 2 distinct possibilities...

1. The Shipping process failed to insert the row

or

2. The trigger failed, and thus the underlying action (writing the shipment
record) fails as well.

Is there any way to construct (or error trap) the trigger, such that the
underlying row gets written to the Shipments table (even if the subsequest
actions fail) ?  Also, how to log the failure ?

Rob (rwch***@comcast.net) writes:
Show quoteHide quoteI've been trying to understand this, and may be that it's the end of a
working week and time for bed, but I can't really get it together.

As I understand it, you first insert rows into Shipments, and then
the trigger on Shipments inserts rows into Invoices (or updates).

Then you say the rows in Shipments are missing. Is the action in
Invoices also missing? Or is that one carried out? Or have I gotten
it all wrong?

If "fails" here refers to an execution error, there should be an
error message somewhere which can give you more information.

Get last date in result set
TOP 10 for each group
UDF that take a UDT as a parameter (CLR)
Table reaching max value of identity very early
Crosstab, Pivot?