GilaMonster (1/7/2013)

---

The most selective one (the one that, based...

I suggest a hybrid method.

Do something like the first method except that you begin new transactions only at certain record counts, for example, every 2000 values processed:

record #1; record #2001;...

With a clustered index on ( A, B, C ) and a

WHERE A = 6 AND C = 7

I would expect SQL to a clustered index seek.

That is, it will...

paul.j.kemna (1/7/2013)

---

The actual syntax would be :

DECLARE @StartDate as date

SET @StartDate = some calculated date

DECLARE @EndDate as date

SET @EndDate = another calculated date

CONVERT([varchar](10), MyDatetimeColumn, 101) AS MyDate

...

WHERE MyDate >=...

CELKO (1/4/2013)

---

The power employees I work with regard me as the "Data...

CELKO (1/4/2013)

---

As I said, read books on basic Software Engineering. Yourdon and Constantine's STRUCTURED DESIGN is still classic. Chapters 6 and 7...

CELKO (1/4/2013)

---

I see that you also confuse rows and...

CELKO (1/4/2013)

---

Since SQL is a database language, we prefer to do look ups and not calculations. They can be optimized while temporal math messes up optimization. A useful idiom is...

Do you have only a few clients with huge numbers of orders each?

Or for a large number of clients, some with large numbers of orders, some with small numbers of...

Those embedded REPLACEs are looking more tempting now, huh? 🙂

dwain.c (1/3/2013)

---

ScottPletcher (1/3/2013)

---

That "we" is undefined and thus meaningless. But people who have...

Lynn Pettis (1/3/2013)

---

You mean something like this?

DECLARE @TestStr VARCHAR(20) = 'QWERY56920TYEU';

SELECT @TestStr;

WITH eTally(n) AS (SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) FROM sys.all_columns a CROSS JOIN sys.all_columns b)

SELECT

...

Embedded REPLACEs is your best option really, from a performance standpoint.

You could generate the REPLACE statements so you didn't have to write them by hand.

.

GilaMonster (1/3/2013)

---

kwoznica (1/2/2013)

---

You also wrote

I take that this is a suggestion to make the phone_contact table a wider table to...