The article is under construction atm, but I've prettymuch got it memorized :hehe:. The whole theory works off of using the clustered index to update the table. You *must* both create and specify this clustered index in the order that the rows should be read. It will usually work fine regardless, but without specifying the index, it *could* fail.

Here's an example of it all in one pass. (I inserted the data into a temp table #multrecs instead of his default multrecs)

Ugh, this thing murders my formatting :crying:

-------------------- Solution -----------------------------

ALTER TABLE #multrecs ADD Display bit

CREATE CLUSTERED INDEX Quirky ON #multrecs (acct,cdt,val,ndt) -- <----- Note this clustered index. Very important.

DECLARE @PrevAcctbigint,

@PrevCDTdatetime,

@PrevValvarchar(20),

@LDNDTdatetime,--Last Displayed NDT

@Displaybit-- Even though you don't use it, this won't function without the 3 part update

UPDATE #multrecs

SET @Display = Display = CASE WHENAcct = @PrevAcct

AND CDT = @PrevCDT

AND Val = @PrevVal

AND DATEDIFF(d,@LDNDT,NDT) < 38

THEN 0

ELSE 1

END,

@LDNDT = CASE WHENAcct = @PrevAcct

AND CDT = @PrevCDT

AND Val = @PrevVal

AND DATEDIFF(d,@LDNDT,NDT) < 38

THEN @LDNDT

ELSE NDT

END,

@PrevAcct = Acct,

@PrevCDT = CDT,

@PrevVal = Val

FROM #Multrecs WITH (INDEX(0))

SELECT * FROM #MultRecs

WHERE Display = 1