Global db settings?



  • Hi,

    The other day I had a slightly odd experience, that you might appreciate. We develop software (ranging from simple queries to web-based viewers) using a development environment, that includes an Oracle server. For production, everything is moved to the production environment, that has its own Oracle server. Everything seemed to work fine, but someone noticed that the reports from the production environment didn't make sense. Turned out that NLS_TERRITORY was different on both systems, and that made that one system thought of Sunday, and the other of Monday as the first day of the week. Then, at the end of March, when our DST kicked in, the hour shift was different on both systems too. Turned out that both the database timezone and the session timezone were set differently on both servers.

    I don't know if that happens on other db systems, but this made me hate Oracle just a bit more (this, and the fact that empty strings are NULL, of course, and you can't have NULL in your primary key, and the different flavours of timestamp, and ...).



  • Well in MSSQL, the first day of the week (as returned by @@DATEFIRST variable) is dependent on the language.  The default language is assigned at the instance level, but you can override it in the connection or query if you have the permissions.  I believe you can override the NLS_TERRITORY and NLS_LANG variables when connecting to Oracle as well. 

    IMO, this type of behavior is just good localization practices by the developers.



  • TRWTF is that you think being able to configure software to work outside where you live is a WTF.



  • @TGV said:

    ... you can't have NULL in your primary key, and ...


    ... Why, exactly, would you want a null primary key?



  • @aliquot said:

    @TGV said:
    ... you can't have NULL in your primary key, and ...

    ... Why, exactly, would you want a null primary key?

    Sometimes it's useful to have an empty string in your primary key, or use NULL to represent a "missing" or default value. There is nothing special about NULL that would make it incorrect for use in a primary key. Sometimes it just makes sense.



  • @TGV said:

    Sometimes it's useful to have an empty string in your primary key, or use NULL to represent a "missing" or default value.

    and how do you handle a left join to that table


  • Discourse touched me in a no-no place

    @TGV said:

    @aliquot said:
    @TGV said:
    ... you can't have NULL in your primary key, and ...

    ... Why, exactly, would you want a null primary key?
    Sometimes it's useful to have an empty string in your primary key,
    Example please? Nothing too contrived though.@TGV said:
    or use NULL to represent a "missing" or default value.
    When would you have a 'missing' or default primary key?

     


  • Discourse touched me in a no-no place

     @PJH said:

    When would you have a 'missing' or default primary key?

    Composite primary keys. They're actually pretty fucking useful.



  • @Weng said:

    @PJH said:
    When would you have a 'missing' or default primary key?
    Composite primary keys. They're actually pretty fucking useful.
    And most people would identify they were talking about Composites... we all figured the item under discussion was non-composite keys... I hear it's not a foreign concept


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.