Author: way0utwest

  • FORMATing Dates

    I’m writing this post as a way to help motivate the #SQLNewBloggers out there. Read the bottom for a few notes on structuring a post.

    FORMAT is a function that was introduced in SQL Server 2012. It is designed to format dates and numbers as date/times. It was added to try and reduce the complexity and cumbersome nature of CONVERT and CAST.

    What I didn’t know, which I did like, is that the FORMAT command can be driven by language settings. For example, if I take a specific date, like today, I can reformat the date based on a language code.

    DECLARE @d DATETIME = GETDATE();
    SELECT FORMAT ( @d, 'd', 'en-US' ) AS 'US English Result'
          ,FORMAT ( @d, 'd', 'en-gb' ) AS 'Great Britain English Result'
          ,FORMAT ( @d, 'd', 'de-de' ) AS 'German Result'
          ,FORMAT ( @d, 'd', 'zh-cn' ) AS 'Simplified Chinese (PRC) Result'
    
    

    The results of this code are different, based on the cultural settings. Of course, the Chinese settings is really the only good way to show dates without confusion.

    dateresults

    This is interesting in that if you can get the regional settings for the client, you can easily return data in a format that makes sense to the user. Of course, we typically don’t want to do too much formatting on the server.

    The default language is that of the current session. For dumb uni-lingual people like me, this isn’t an issue, but it might matter for people that speak multiple languages and might move from system to system.

    It is interesting in that you can easily format the data from a date with FORMAT. For example, I change orders to match the Chinese format:

    DECLARE @d DATETIME = GETDATE();
    
    SELECT FORMAT( @d, 'YYYY/MM/DD');
    
    

    That gets me “2015/07/20”.

    I can easily change to other formats, adding in times, or even partial times that might not make sense. For example, the result below named “Hours” has only the date. The “Date and hours” has the date and the hour only.

    DECLARE @d DATETIME = GETDATE();
    
    SELECT  'Default' ,
            FORMAT(@d, 'd')
    UNION
    SELECT  'Full Date' ,
            FORMAT(@d, 'YYYY/MM/DD hh:mm:ss.ffff t zzz')
    UNION
    SELECT  'Date and hours' ,
            FORMAT(@d, 'YYYY/MM/DD hh')
    UNION
    SELECT  'Date and minutes' ,
            FORMAT(@d, 'YYYY/MM/DD mm')
    UNION
    SELECT  'Hours' ,
            FORMAT(@d, 'hh');
    
    
    
    --      ,FORMAT ( @d, 'yymmdd', 'en-gb' ) AS 'CleanUS'
    
    

    The results are:

    Date and hours    2015/11/20 04

    Date and minutes  2015/11/20 11

    Default           5/20/2015

    Full Date         2015/11/20 04:11:28.9600 P -06:00

    Hours             04

    I think that there are lots of reporting queries where the formatting of dates would be handy and easier with FORMAT than CONVERT. It certainly is more intuitive to read than seeing something like “,110” in code.

    I still have the habit of using CAST and CONVERT when I’m changing types, and I’ll continue to do that. Especially as FORMAT is really limited to date types.  However when trying to get dates to render in proper formats, it’s a good choice.

    SQLNewBlogger

    This post came about while I was checking on another issue. I happened to run into the FORMAT command and hadn’t used it much, so I spent a few minutes messing around. This post came out of around 5 minutes of experimentation and 15-20 minutes of writing.

    References

    FORMAT – https://msdn.microsoft.com/en-us/library/hh213505.aspx

    Formatting Types in the .NET Framework – https://msdn.microsoft.com/library/26etazsy.aspx

  • What Not To Say

    This editorial was originally published on Jan 26, 2011. It is being re-run as Steve is out of town.

    This article on 8 things your boss doesn’t want to hear made me smile. There are a few phrases listed that I would definitely recommend not using if you want to succeed in your current place of employment.

    Having managed a few DBAs in my career, I thought of a few more that I thought might fit the data professionals out there as “things not to say” to your boss:

    I’m not sure if more memory will help: You could substitute CPU or disk drives for memory in this one, but it’s your job to know. If you don’t, learn how to tell what your bottlenecks are and make appropriate recommendations.

    That additional memory didn’t help: The only thing worse than not being able to make a good recommendation is making one that doesn’t improve performance after your boss has approved the purchase. Now you look bad, and you’ve made your boss look bad.

    Company X has offered me $yyyyy. Will you match it? You can get away with this once at a job, or maybe once a decade. If you want to go to your boss with this one, be ready to quit if you don’t get it, and be ready to shine if you receive the raise. No one wants to be put in a corner, and I would be likely to let you move on if you came to me, unless I felt you deserved it. Even then, the second time you ask, I’m showing you the door.

    I downloaded this software off the Internet and it crashed the server: You can’t trust stuff you download, no matter what the Open Source crowd says. Test, test, test. Preferably on a test machine.

    It works on my machine: I have always wanted to answer this with a “Who gives a <insert four letter expletive here>?” My actual responses haven’t been that far away if it’s an important project and you give me this excuse.

    Feel free to add your own “things not to say” to the comments below.

     

  • Finding Production Drift

    A few years ago when I started delivering presentations about automating database delivery with Grant Fritchey, I was surprised by something. We were rehearsing a talk and Grant mentioned that there were really only two places where we knew the state of our code: in a VCS and in production. I hadn’t really thought about that before, but realized it was true.

    While the development environments are always in flux, by using a VCS, you can determine the state of your code at any point in time. However since changes can occur in production (DBAs adding indexes, changing security, etc), you can’t count on a release branch of some other designation as being a guarantee of the state of your live environment. Production is always its own version of the truth.

    Ideally all of the changes being made on your production system are tested in development, QA, and pre-production environments before being deployed, but very few companies have a mature enough deployment pipeline to allow them to push hot fixes and patches rapidly enough, especially when they need to be made in an emergency.

    More than likely some changes will always be made in production directly, especially small ones that affect data. You can’t prevent this, but you should be able to deal with the aftermath and ensure that your system doesn’t destabilize from the enhancements. Without a doubt DBAs should log any scripts they run, but it’s easy to forget things, especially when changes are made in firefighting mode or at 3am.

    That’s why having some sort of monitoring system to watch production for any changes becomes an important logging mechanism for DBAs. Whether you build one yourself, or buy some software, you use the native tools or bolt something onto SQL Server, make sure that you put something in place. Work to push your ad hoc changes back to development, and ensure they get into a VCS at some point.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Your Job

    This quote is a great:  “I don’t really care if your code runs locally. If your code just runs locally, then my only option is to sell your computer so that our users can use our software, and that really doesn’t scale.” That quote is from an open letter to engineers and talks about what the job of a software engineer really is. It’s not just to write code, but to make sure our code and the entire system works for users.

    That’s important. It doesn’t matter how well you code if the application only works on your machine. We traditionally haven’t been great at getting code from one system to another and ensuring it works, at least not in a smooth fashion. We haven’t really followed an “engineering” process when we write, and deploy, software.

    The DevOps movement is changing this a big, bringing automation, scripting, and repeatability to both software development and operational deployment. All of these things should help us adhere to a more repeatable engineering practice. The commoditization of powerful hardware has also helped as many client environments might be nearly as powerful as development systems these days. It also means that our test systems can be good substitutes for production systems, at least if we can quickly build up and tear down large virtual environments.

    However we still need to be sure that we always remember that our code needs to work on other systems. Whether it has to scale down to meet the needs mobile devices or slightly older browsers and desktops, or our code needs scale up to handle thousands of times more transactions on a production database server than it processes on our laptops. We have to always consider the needs of the end user environment as we develop software. We need to test it in those situations, and broaden our skills to ensure that our applications satisfy the needs of the clients. And, of course, we should be able to quickly and easily deploy our changes to any other environment.

    Steve Jones

     

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn.