You could do comparisons after the fact using the auditing data, but that would be big overhead.

You don't need separate triggers for the original trigger to indicate which column(s) were...

The problem with the all digits string is it can be mistaken for an integer.

100% false.  Date literals are strings, or delimited in some other way to distinguish them from...

This might give better performance, if the optimizer recognizes the chance:

WHERE AKey LIKE '[ABCDEGJ]%' AND (AKey LIKE 'AAA%' OR AKey LIKE 'BBB%' OR AKey LIKE 'CCC%' OR...

And if my suggestions are broken, are so bad, why do the recent DATE and DATETIME2(n) data types default to it?

Default to what exactly?  We know they're not stored in...

I disagree; when at all possible, you want to make the clustered index unique yourself whenever possible.  Yes, SQL will always force it to be unique anyway, but that often...

I'd say just use > CHAR(0) if you're going to go that route.  Btw, wouldn't you have to use >= CHAR(9), just in case only a tab char was there?

And that's why I wrote the code the way I did.  The other way is somewhat easier to code, but potentially far worse in performance.

The underlying rule is:

Never use a...

2) these display strings sort correctly in temporal order. They are not ambiguous.

As I stated, In the real world dates are sometimes given as YYYY-DD-MM for certain regions of the...

Actually, the format YYYYMMDD is perfectly acceptable under ISO.  I don't know why Celko insists on repeating his false claim over and over about YYYY-MM-DD despite being told that it's...

You probably need something like this:

WHERE (AKey LIKE 'AAA%' OR AKey LIKE 'BBB%' OR AKey LIKE 'CCC%' OR AKey LIKE 'DDD%' OR
    AKey LIKE...

Don't convert a column to a different data type unless you absolutely can't avoid it (sargability and all).  For your situation, this should handle both dates and the -1 properly. ...

Thanks for the follow up.

Now it's back to the old approach -- you have to go thru the query plan query by query and tune each separately (and perhaps consolidate...

There's nothing per se wrong with CREATEing the table using INTO; indeed, it can help prevent future errors when data types changes, for example.  But, you don't want to load...

Hmm, interesting.  With those symptoms, I'd probably first look for a physical reason.  Bad RAM, bad NIC, bad local drive, some physical failing on one node vs the other.

An inline TVF should perform better, although how much better it's very difficult to estimate.  I've done the best I can converting this in a short time, you may need...