And don't forget about computed columns. You can make this a computed column, so you don't have to have the generating code in a trigger. Since it's a...

I disagree completely.

I've repeatedly gotten huge performance gains sometimes by indexing temp tables properly. They are tables like any other table, after all. For large tables, I've seen...

You could also use an INNER JOIN to a hard-coded table:

select

case parents.whichParent when 'father' then s.father when mother then s.mother else s.parent_guardian end,

...

CELKO (12/14/2012)

---

But it is fast and portable 😀

On a more serious...

CELKO (12/14/2012)

---

Yeah, it was awful! :crazy:

What I wanted to do was...

Sorry, I didn't have test data so I couldn't pre-test it myself.

If you'll post some data as INSERT statements, I'll be happy to correct the query.

GSquared (12/14/2012)

---

CELKO (12/13/2012)

---

Please read just one little book on SQL and RDBMS. Please, just one little book! This is not a table; it has no key;...

CELKO (12/13/2012)

---

Please read just one little book on SQL and RDBMS. Please, just one little book! This is not a table; it has no key; it...

SELECT object_name, database_name, DATEPART(Week, event_time) AS EventWeek, SUM(sequence_number) AS [#TimesAccessed],

DATEADD(HOUR, DATEDIFF(HOUR, 0, event_time), 0) AS [EventHour]

INTO #EventHour

FROM ...

ScottPletcher (12/12/2012)

---

CELKO (12/11/2012)

---

In COBOL, the display and the internal format of data was the same. Each field had a PICTURE clause to define it. Your question makes sense only in...

It's normal IF the indexing on the data was not optimal, so that you were scanning old data before that has now been removed.

Note that when you DELETE a large...

Only 'YYYYMMDD', rather than 'YYYY-MM-DD', is 100% safe:

INSERT INTO T1 (createdate)

VALUES ('20120309 12:34:45:567')

I'd suggesting not using that particular new "enhancement" at all while you still have ANY older instances / compatability settings.

It doesn't save you that much anyway. Not worth the...

Whenever possible, you should use:

EXEC sp_executesql @sql [rather than EXEC(@sql)]

because it is far less susceptible to SQL injection, although not foolproof depending on what...

Here's another possible approach, in case you ever have to do (many) more columns 🙂 :

DELETE FROM dbo.trefClientShares

WHERE

CASE WHEN intLMid IS NULL THEN 1 ELSE 0...