I agree, the first method is unnecessary.

As to whether I put all on one line: if they are straightforward, I would code them in one line with ANDs.  If one...

I really hope this isn't a dumb question. Is there a reason other then style or preference as to why you'd do this:

IF @Var1 =...

Unfortunately, we have a bit of a standard, which is that tables called "Thing" have a clustered index on ThingID, which will be an int, identity column. That's because...

The obvious difference is the number of rows read from the T_DeliveryTimetableItemResolvedCost table, which goes from 20k to 21 million (and a seek to a scan, probably unsurprisingly). The...

>>Use INSERT instead of MERGE in the second statement.

How would I then handle duplicates? I don't want to insert a duplicate record if there already is one that matches...

Since you only want monthly totals, I don't see any reason for the overhead to create a row for every single day; instead, you really only need a row for...

The SERIALIZABLE would cause higher levels of locks and cause them to be held longer.

Use INSERT instead of MERGE in the second statement.

Personally I'd use an UPDATE then INSERT on...

I guess the sequence must be called so many times that you're running out of values for an int.

Maybe use a bigint for the sequence?

I can't test these since you didn't provide directly usable test data:

--if you need only the acct_ids
SELECT acct_id, COUNT(*) OVER() AS total_accts
FROM my_table
GROUP BY acct_id
HAVING MIN(street +...

As noted by Brian, your table design is completely wrong.  You've then had to corrupt the data to fit it into the bad table structure.

For example, the language is "English". ...

I think there is one way you can try the upgrade path.

IF your san/disk/software allows you to snapshot a given point-in-time on disk, and accurately restore everything on disk (including...

OP = "original poster", i.e., the person that originally asked the q (or, rarely used and only by some people, "original post")

The actual database and logfiles should preferably be kept on same drives as they are now.

The most simple approach I can come up with is:

• Detach the database in...

I think you're correct, you should do this for all tables.  No sense wasting resources scanning a 900-row table either.  Of course that 900 rows could be far...

I think you're correct, you should do this for all tables.  No sense wasting resources scanning a 900-row table either.  Of course that 900 rows could be far larger than...