4 ms·

SQL Server didn't introduce MERGE until 2008, so not quite 15 years. Also SQL Server bugs can take a long time to be fixed, if at all: https://www.mssqltips.co

SQL Server didn't introduce MERGE until 2008, so not quite 15 years. Also SQL Server bugs can take a long time to be fixed, if at all: https://www.mssqltips.com/sqlservertip/3074/use-caution-with-sql-servers-merge-statement/ https://www.mssqltips.com/sqlservertip/3074/use-caution-with... In my own experience of working with MS SQL Server since 1998 (6.5), Microsoft are fairly conservative about changes to the core database engine, despite seeing new releases every year or so. New features tend to be stuff built on top of the engine. In real life you're far more likely to encounter older versions of SQL running mission critical apps because upgrades are that one time where you're likely to screw up the crown jewels (your data), and so therefore many organisations tend to be conservative about that too. Now it's nice to get to work on a greenfield application where you can kick off on a shiny new version of SQL, but there's a good chance those bugs and behaviours are still likely to be present because the core engine is pretty much the same.

gfody 6y ago
with all due respect to Aaron, I've had this link shown to me by developers not wanting to write a simple merge statement instead of some block of semantically weird shit full of lock hints enough times for it to be annoying. be careful, of course, but don't be superstitious - start with straight forward code and test.
- cogman10 6y ago
  The problem with merge is that it fails under contention, not under simple testing. We've had multiple issues with SQL Server caused by the usage of MERGE statements. It's been bad enough that we've ended up banning them as an organization in favor of the block of "semantically weird shit". Why? Because that block has become common, clear, and most importantly, doesn't tend to cause weird deadlocks, race conditions, etc.
  - gfody 6y ago
    > The problem with merge is that it fails under contention, not under simple testing. that depends on so much else going on with your database - fine policy but when I said "test" I didn't mean whatever you mean by "simple testing". > caused by the usage of MERGE statements "exacerbated by" is probably more accurate - just because replacing a merge statement with something else alleviated an issue doesn't mean that the root cause was some bug in SQL Server.

gfody 6y ago

with all due respect to Aaron, I've had this link shown to me by developers not wanting to write a simple merge statement instead of some block of semantically weird shit full of lock hints enough times for it to be annoying. be careful, of course, but don't be superstitious - start with straight forward code and test.

cogman10 6y ago
The problem with merge is that it fails under contention, not under simple testing. We've had multiple issues with SQL Server caused by the usage of MERGE statements. It's been bad enough that we've ended up banning them as an organization in favor of the block of "semantically weird shit". Why? Because that block has become common, clear, and most importantly, doesn't tend to cause weird deadlocks, race conditions, etc.
- gfody 6y ago
  > The problem with merge is that it fails under contention, not under simple testing. that depends on so much else going on with your database - fine policy but when I said "test" I didn't mean whatever you mean by "simple testing". > caused by the usage of MERGE statements "exacerbated by" is probably more accurate - just because replacing a merge statement with something else alleviated an issue doesn't mean that the root cause was some bug in SQL Server.