Why does all cursor code look like FETCH NEXT ... WHILE @@FETCH_STATUS = 0 BEGIN .... FETCH NEXT ... END and not like this: WHILE 1=1 BEGIN FETCH NEXT ... IF @@FETCH_STATUS <> 0 BREAK; .... END
I wish there was some simpler syntax for it, something like LOOP FOR SELECT ... BEGIN do some stuff END;dbfiddle.uk/XEG1Quvz
I guess that goes with wishing there was a dynamic_sql data type where you could actually build a proper dynamic query without risking compilation errors.
SQL really does need to up its game and move into the new millenium...
@PaulWhite-OnStrike Your Trigram article has the following comment -- Binary collation comparison so ranges work as expected what does that mean exactly? Surely any collation has a specific sort algorithm and should be deterministic over that sort? Any case you don't seem to be doing any range seeks?
@PaulWhite-OnStrike Yes WHERE T.trigram COLLATE Latin1_General_BIN2 NOT LIKE '%[^A-Z0-9a-z]%' but why would that make a difference? Are there any collations where A-Z0-9a-z are not sequential? And is there a perf loss by the collation conversion, or if anything is it faster to use a binary collation?
Re the perf difference, do you have anything on that? On the one hand, you would think a binary collation is faster to sort. On the other SQL Server is weird like that when it comes to conversions.
In this particular case indexing is not relevant, purely the existing value vs converting it.
[0-9] is not some type of regular expression defined to just match digits.
Any range in a LIKE pattern matches characters between the start and end character according to collation sort order.
SELECT CodePoint,
Symbol,
RANK() OVER (ORDER BY Symbol COLLATE Latin1_General_CI_AS) AS...
[0-9] is not some type of regular expression defined to just match digits.
Any range in a LIKE pattern matches characters between the start and end character according to collation sort order.
SELECT CodePoint,
Symbol,
RANK() OVER (ORDER BY Symbol COLLATE Latin1_General_CI_AS) AS...
