February 13, 2016 at 12:33 pm
Comments posted to this topic are about the item HEX conversions
February 13, 2016 at 11:19 pm
Not using this much, so learned somthin new, thanx.
Thanks & Best Regards,
Hany Helmy
SQL Server Database Consultant
February 14, 2016 at 6:56 pm
One of many good reasons to always know your data and use explicit sizes for datatypes.
--Jeff Moden
Change is inevitable... Change for the better is not.
February 14, 2016 at 11:01 pm
This was removed by the editor as SPAM
February 15, 2016 at 1:23 am
Was this inspired from QotD "Converting hex values" on Feb 9 ?
"repeating is the mother of knowledge"
Thanks
Igor Micev,My blog: www.igormicev.com
February 15, 2016 at 7:06 am
Igor Micev (2/15/2016)
Was this inspired from QotD "Converting hex values" on Feb 9 ?"repeating is the mother of knowledge"
Thanks
I was thinking the exact same thing.
February 15, 2016 at 7:15 am
Jeff Moden (2/14/2016)
One of many good reasons to always know your data and use explicit sizes for datatypes.
Yes, datatype lengths and scales are NOT good things to use defaults for, and T-SQL would have been a better language if there were no defaults for these parameters of a datatype because that would have prevented a very large number of coding errors.
Typing the required length/precision and scale is not a big hassle, so these defaults don't have much value for the DBA or the developer (unlike some good effort-saving security defaults that some people say should never be used) and do have significant cost in dealing with the extra bugs that result from using them. And learning what all the length/precision/scale defaults is a real pain for beginners because (a) there's no rhyme or reason to them and (b) they can be diferent in different contexts (declarations, conversions) - which is of course pure lunacy - and (c) the defaults are at best rarely (almost never) the values needed so they don't provide any useful payback for the hassle of learning them all.
Tom
February 23, 2016 at 5:24 am
I've helped several people at work where they just couldn't figure out why something so simple wasn't working and it turned out that they used varchar variables with the default length. Get burned once and have it cost you an hour of head-scratching and you'll retain it - always use specific lengths.
March 8, 2016 at 4:58 pm
This was familiar, thanks.
March 8, 2016 at 5:23 pm
Ed Wagner (2/23/2016)
I've helped several people at work where they just couldn't figure out why something so simple wasn't working and it turned out that they used varchar variables with the default length. Get burned once and have it cost you an hour of head-scratching and you'll retain it - always use specific lengths.
Not only that, but folks REALLY need to pay attention to front end code when it comes to datatypes. I just fixed yet another bloody Entity-Framework-caused, really nasty performance problem with some newly released code. It was using NVARCHAR(4000) datatypes to compare to a CHAR(10) column and NVARCHAR(MAX) to compare to a VARCHAR(30) column. It was taking ~1 SECOND of duration, 3-4 SECONDS of CPU time, and 40,000 logical reads (that's 327.7 MEGA BYTES of memory IO)... to process ONE bloody row at a time! A typical "batch" of documents contains 2,000 rows (document processing) and we have between 5 and 25 such batches per day. It never caught up.
Once repaired, each run (they kept it at single row) took less than a millisecond, CPU time couldn't be measured, and the number of reads dropped down to just 4. Of course, there was also no longer a need for parallelism either.
This wasn't complicated code, either. One was a simple SELECT with no joins and the criteria was applied to the PK of the table. The other was an equally simple UPDATE.
This is a more common and widespread problem than I could ever have imagined. I've taken one company under my wing because they can't afford a "DBA" but they deserve to succeed and so I help them here and there for the bubble. None of them know about this problem nor how to do "annotation" in EF to keep it from happening and the CEO has this wild hair up his butt about "portability" and refuses to use stored procedures. I didn't realize it until I found today's problem where I work but the folks in my shop didn't know that this problem existed in EF even though I had shown them that it existed in Linq2SQL about 4 years ago.
Ok... I'm going to calm down and meditate for a minute. Please join me... say it nice and slow... just like an ORM. :w00t:
OOOORRRRRMMMMM... OOOORRRRRMMMM... OOOORRRRRRMMMMS SSSSUUUUCCCCKKKK. 😛
There... I feel much better now. Don't you!? :hehe:
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2016 at 11:30 am
Thanks for the question.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply