3 ms·

MSSQL was an excellent product since version 7. Reporting bugs and getting support for MSSQL 2000 was a good and rapid experience. It's just gone downhill slowl

MSSQL was an excellent product since version 7. Reporting bugs and getting support for MSSQL 2000 was a good and rapid experience. It's just gone downhill slowly since. The documentation at that time was first class too - it's important to remember that, docs really matter. In 2014 the small company I worked for made a release with my work in it and I was spoken to the next day because it had crashed. The boss was not pleased as it had to be down to my work, nothing else had changed. In fact it was down to geographical data in the DB being changed as well. One of the geog functions (edit: think it was STIntersects, but the next bit applies to many such functions) claimed to return a 0 or a 1 - but in fact I found, separately documented, that it could also return NULL. While spending a couple of hours digging this out, I found via a blog that geography data types used approximate algorithms (which is not surprising, and quite reasonable when you understand why, but it was not documented). These two problems caused us what could have been a serious production problem. There's lots more. I've hit too many. Just a few weeks ago I did a straightforward recursive CTE on a small data set, which took a minute to run. Eh? It was an optimiser bug. Breaking off the base query into a temp table first and it dropped to a second. I've too much of this shit, much more. MS doesn't care. BTW if you use the long-existing "update from ...join" syntax which MS released years ago as an extension, be aware it allows you to do stupid things that ansi-standard SQL does not, like repeated unpredictable updates to the same row, in the same single sql statement. I hit that last year in someone else's code. It's broken. Well, what's new.

throwaway_pdp09 6y ago
Just a small one, > select isnumeric('$+.') > 1 so it thinks it's a number but obviously it isn't > select cast('$+.' as int) > Conversion failed when converting the varchar value '$+.' to data type int. This kind of thing makes data cleaning even less fun than it is. They now have TryParse(), but the above (which I'm pretty sure used to allow an even wider range of crap) is just unnecessary, and is a sign of how they view their own flagship product.
csharptwdec19 6y ago
So much of microsoft's documentation is like this nowadays. There's parts of the 'What's new in C# 8.0' that aren't really there, and the provided code samples are entirely wrong (i.e. not just one issue, the language literally can't do the feature.) See also the state of most documentation for ASPNETCORE. > BTW if you use the long-existing "update from ...join" syntax which MS released years ago as an extension, be aware it allows you to do stupid things that ansi-standard SQL does not, like repeated unpredictable updates to the same row, in the same single sql statement. I hit that last year in someone else's code. It's broken. Well, what's new. I'm curious if you have an example. I know it's not ANSI standard but I've yet to run into any issues. MERGE on the other hand is a dumpster fire and everyone knows it.
- throwaway_pdp09 6y ago
  Merge... christ. When I saw the list of fuckups around that my heart sank, it's such a nice statement, if only it worked. I've chosen never to use it (in MSSQL). As for update from, see here https://www.sqlservercentral.com/forums/topic/is-update-from-only-available-in-sql-2005#post-1530797 https://www.sqlservercentral.com/forums/topic/is-update-from... IIRC If you join on unique columns you're safe, but like I said, I found 2 cases of this last year in some code where the cols joined were not were not unique. That meant the output was, quite simply, junk.
  - csharptwdec19 6y ago
    Ahhhhh... I've never run into that issue, but I can see how it would be frustrating. I guess I've always just taken those risks from a cross-join for granted. Possibly because I cut my teeth on Oracle 10g, and when you are having to consistently write update statements the ANSI way you get in the habit of making sure that you'll only get a single record per row. Unless I know the table in FROM is going to be 1-1 I'll make sure to consider the right way to put a TOP 1 in (usually null merges)

throwaway_pdp09 6y ago

Just a small one, > select isnumeric('$+.') > 1 so it thinks it's a number but obviously it isn't > select cast('$+.' as int) > Conversion failed when converting the varchar value '$+.' to data type int. This kind of thing makes data cleaning even less fun than it is. They now have TryParse(), but the above (which I'm pretty sure used to allow an even wider range of crap) is just unnecessary, and is a sign of how they view their own flagship product.

csharptwdec19 6y ago

So much of microsoft's documentation is like this nowadays. There's parts of the 'What's new in C# 8.0' that aren't really there, and the provided code samples are entirely wrong (i.e. not just one issue, the language literally can't do the feature.) See also the state of most documentation for ASPNETCORE. > BTW if you use the long-existing "update from ...join" syntax which MS released years ago as an extension, be aware it allows you to do stupid things that ansi-standard SQL does not, like repeated unpredictable updates to the same row, in the same single sql statement. I hit that last year in someone else's code. It's broken. Well, what's new. I'm curious if you have an example. I know it's not ANSI standard but I've yet to run into any issues. MERGE on the other hand is a dumpster fire and everyone knows it.

throwaway_pdp09 6y ago
Merge... christ. When I saw the list of fuckups around that my heart sank, it's such a nice statement, if only it worked. I've chosen never to use it (in MSSQL). As for update from, see here https://www.sqlservercentral.com/forums/topic/is-update-from-only-available-in-sql-2005#post-1530797 https://www.sqlservercentral.com/forums/topic/is-update-from... IIRC If you join on unique columns you're safe, but like I said, I found 2 cases of this last year in some code where the cols joined were not were not unique. That meant the output was, quite simply, junk.
- csharptwdec19 6y ago
  Ahhhhh... I've never run into that issue, but I can see how it would be frustrating. I guess I've always just taken those risks from a cross-join for granted. Possibly because I cut my teeth on Oracle 10g, and when you are having to consistently write update statements the ANSI way you get in the habit of making sure that you'll only get a single record per row. Unless I know the table in FROM is going to be 1-1 I'll make sure to consider the right way to put a TOP 1 in (usually null merges)