Is this acceptable? No.

Can this be improved? Yes.

Most importantly, you do not need an identity column on two of these tables. Despite what some people may imply, there's no...

The real solution is very likely to cluster the table on event_date, if that is how you most often query the table. You'll get minimum I/O without having to...

TheSQLGuru (11/8/2016)

---

I disagree on...

It depends on how complex the trigger logic and how much different it is for each type of modification whether you want separate triggers or not.

But you can definitely simplify...

drew.allen (11/3/2016)

---

ScottPletcher (11/3/2016)

---

You could try limiting the pattern matching to only the text between "[whitespace-char]WHERE[whitespace-char]" and the next occurrence of "GROUP BY" or "SELECT". Of course that's also not...

drew.allen (11/3/2016)

---

ScottPletcher (11/3/2016)

---

I avoid the ISNULL "tricks" when I can in favor of straightforward code:

UPDATE table_name

SET Foo = CASE WHEN Foo > '' THEN ', ' ELSE '' END +...

J Livingston SQL (11/3/2016)

---

which I believe is what...

You could try limiting the pattern matching to only the text between "[whitespace-char]WHERE[whitespace-char]" and the next occurrence of "GROUP BY" or "SELECT". Of course that's also not perfect, but...

SELECT

SD.NUMBERS

,RIGHT('0000000' + REPLACE(NUMBERS, '.', ''), 7)

FROM SAMPLE_DATA SD;

I avoid the ISNULL "tricks" when I can in favor of straightforward code:

UPDATE table_name

SET Foo = CASE WHEN Foo > '' THEN ', ' ELSE '' END + 'newvalue'

Sorry, don't have a lot of time, but here's my best guess at what could help:

SELECT i.Item_ID AS Kit_SID

, i.Item_ID AS Kit_ID

, i.Item_NO AS Kit_NO

...

You would at least have to remove anything that used a feature available in Enterprise Edition that's not also available in Standard Edition. No compressed tables, etc..

But once...

Hard to determine exactly what you want, but my best guess is something like below; adjust the case conditions to be specifically what you need them to be:

select *

from (

...

mitzyturbo (11/1/2016)

---

As I have 2 log tables to pull data from, how would this work?

do you mean by just having a clustered index by the modified date on both log...

Properly clustering should still allow a merge join, which should be much faster than anything you're having to do now.