Yeah, those scalar ops can be ignored as far as performance goes, as long as they aren't repeated a million times or so.

I would think the subquery would (almost) certainly be able to take advantage of the fact that the query only needs to lookup a single Shipment_No, rather than processing all...

If you don't need the parameters, or they require too much overhead to log, then don't log them.

Just capture the start time, as a datetime2, and the proc name (or...

Thanks for that, now I'm clear.

Yeah, I think the first query you posted should do that.

As to performance, make sure the s and p tables have an index...

Thanks for that, now I'm clear.

Yeah, I think the first query you posted should do that.

As to performance, make sure the s and p tables have an index on Shipment_No...

If I understand your requirements correctly, the code below will do what you want.

As to performance, make sure the s and p tables have an index on Shipment_No...

If I understand your requirements correctly, the code below will do what you want.

As to performance, make sure the s and p tables have an index on Shipment_No and that...

The parms and values where concatenated into...

Add code to the start of the proc to log to table.  While you're at it, you might as well log all the parameter values as...

Add code to the start of the proc to log to table.  While you're at it, you might as well log all the parameter values as well, if...

You could automate the change easily enough (including grabbing the parameters), but I understand the reluctance to change all the procs.  You would likely want to capture the previous modify_dates...

Add code to the start of the proc to log to table.  While you're at it, you might as well log all the parameter values as well, if you have...

Yeah, EXCEPT should to that just fine:

SELECT * /*...list_of_cols...*/

FROM dbo.today

EXCEPT

SELECT * /*...list_of_cols...*/

FROM dbo.yesterday

Yep, exactly.

Use NOT EXISTS when possible, as it allows for better execution plans.