Post reply

Datefirst

  • September 12, 2013 at 10:12 pm

    #279703

    Comments posted to this topic are about the item Datefirst

  • September 12, 2013 at 11:28 pm

    #1649935

    Thanks 🙂

    Thanks
    Vinay Kumar
    -----------------------------------------------------------------
    Keep Learning - Keep Growing !!!

  • September 13, 2013 at 12:27 am

    #1649943

    Very nice question to close off the week.

    And kudos for mentioning the default language, so there's less whining in the discussion 😀

    Need an answer? No, you need a question
    My blog at https://sqlkover.com.
    MCSE Business Intelligence - Microsoft Data Platform MVP

  • September 13, 2013 at 12:49 am

    #1649953

    Clear and easy question!

    Thanks:-)

  • September 13, 2013 at 12:54 am

    #1649956

    Carlo Romagnano (9/13/2013)

    Clear and easy question!

    Thanks:-)

    +1

    _______________________________________________________________
    To get quick answer follow this link:
    http://www.sqlservercentral.com/articles/Best+Practices/61537/

  • September 13, 2013 at 1:00 am

    #1649958

    The scope of "set language" and "set datefirst" is per session and also per procedure/function

    Try this:

    create procedure proc_datefirst

    as

    set language 'us_english'

    select @@DATEFIRST

    go

    set language 'Italian'

    exec proc_datefirst

    select @@DATEFIRST

  • September 13, 2013 at 2:47 am

    #1649989

    Good one, thank you for the post.

    (so close, and I got this wrong :crying:. Note to self: "connection" and "session" are two different things.)

    ww; Raghu
    --
    The first and the hardest SQL statement I have wrote- "select * from customers" - and I was happy and felt smart.

  • September 13, 2013 at 3:38 am

    #1650000

    Carlo Romagnano (9/13/2013)

    The scope of "set language" and "set datefirst" is per session and also per procedure/function

    Try this:

    create procedure proc_datefirst

    as

    set language 'us_english'

    select @@DATEFIRST

    go

    set language 'Italian'

    exec proc_datefirst

    select @@DATEFIRST

    Easy question...

  • September 13, 2013 at 4:10 am

    #1650005

    Interestingly enough running this in UK, on SQL Server 2012 SP1

    I got

    us_english

    7

    2

    3

    tried it on two 2012 builds got the same result.

    Also same result on 2008 R2 dev edition.

    And on 2008 sp 3 enterprise edition.

    Cheers,

    Rodney

  • September 13, 2013 at 4:12 am

    #1650006

    Silly me, didn't have coffee yet and missed the second part!

    Yes per session!! So new session will be 7

    Rodders...

  • September 13, 2013 at 5:43 am

    #1650022

    Thanks! I will be posting some more in the future. I'm glad you liked it! 😉

  • September 13, 2013 at 6:39 am

    #1650034

    Thanks for the question!

    BTW, I got tired of seeing Steve go on vacation. So, I'm going on one too. Two weeks in Greece, or ????da. The ONLY thing I'll miss about work is doing the QotD every morning. 😉

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

  • September 13, 2013 at 6:56 am

    #1650038

    Interesting, good question...

  • September 13, 2013 at 7:57 am

    #1650052

    Great question to end the week on


    Everything is awesome!

  • September 13, 2013 at 8:24 am

    #1650062

    Almost a nice question, but actually not correct. The assumption that the server default language is us_english isn't adequate; you have to assume that the default language for the login used to connect SSMS to the server is us_english, because the new query will use a new session, which will use the login's default language, not the language that has been set for the first query's session, and the login's default can be different from the server default. The set statement commented "just to make sure" in the first query merely makes sure that the session containing that query will use us_english, not that the other session will.

    In SQL 2012 there's another complication - if it's a contained database, the second call will use the databases default language if the login hasn't set a different default language, and the databases default language may be different from the server default. Was that what the instruction to connect to the same database for the second query as for the first was about? If it's not a contained database, the database is irrelevant; and even if it is, the assumption you need is that the login's default language is us-english. so the database would be irrelevant if the right assumption had been stated instead of an inadequate one.

    Tom

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic. Login to reply