HEX conversions

  • Comments posted to this topic are about the item HEX conversions

  • Not using this much, so learned somthin new, thanx.

    Thanks & Best Regards,
    Hany Helmy
    SQL Server Database Consultant

  • One of many good reasons to always know your data and use explicit sizes for datatypes.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • This was removed by the editor as SPAM

  • 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

  • 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.

    Luis C.
    General Disclaimer:
    Are you seriously taking the advice and code from someone from the internet without testing it? Do you at least understand it? Or can it easily kill your server?

    How to post data/code on a forum to get the best help: Option 1 / Option 2
  • 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

  • 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.

  • This was familiar, thanks.

  • 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


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • 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