Check if a datefield is really a datefield



  • I am working for a big company, and we are using Oracle PL/SQL and a special framework for building programs.


    I found this one from a business analyst who wrote this little gem for a program i'm building:



    (import file in oracle)



    (verifiy data written in oracle)



    Check issue date format:

    If format is not 'DD/MM/YYYY' then write to IMP_ERROR_MESSAGES

    IGE.CODE := IGIS.CODE

    IGE.REMARK := ‘SD: issue date format is not DD/MM/YYYY’

    Endif



    (write from oracle buffer to main database)



    The issue_date field is NOT a string but a genuine date field, in oracle AND in my code. I asked why it was there, because it never got triggered. Reply: "Well, i had to make sure that it didnt break oracle."



  • @mr_seeker said:

    "Well, i had to make sure that it didnt break oracle."
     

    ... that which is already broken.

    {laugh track, freeze frame}



  • @Lorne Kates said:

    @mr_seeker said:

    "Well, i had to make sure that it didnt break oracle."
     

    ... that which is already broken.

    {laugh track, freeze frame}

    Last month we were setting up a pair of dev laptops, and installing the Usual Tools on them, which included Oracle 11g. Both identical machines, identical system images, identical scripts. Oracle installs on one, and crashes during install on the other three times in a row.

    We ended up installing 11b on it, since we had nothing better to do.

    And don't get me started on all the queries it's Optimized to use cross joins...



  • @Buttembly Coder said:

    @Lorne Kates said:

    @mr_seeker said:

    "Well, i had to make sure that it didnt break oracle."
     

    ... that which is already broken.

    {laugh track, freeze frame}

    Last month we were setting up a pair of dev laptops, and installing the Usual Tools on them, which included Oracle 11g. Both identical machines, identical system images, identical scripts. Oracle installs on one, and crashes during install on the other three times in a row.

    We ended up installing 11b on it, since we had nothing better to do.

    And don't get me started on all the queries it's Optimized to use cross joins...

    The machines may have been identical, but I'll bet the second install was at a different time of day. This is Oracle, after all: consistency is too much to expect.



  • That's an easy one to fix.  You're only licensed to run Oracle 11g on machines with less than three point five bogocpuequivalentunits where the product of the size of the memory in gigabytes and the number of hard drives is no more than eight and the serial number is not divisible by three, four or seven.

    Just contact your friendly neighbourhood Oracle rep and see about upgrading your licences to take care of that.  It shouldn't cost you too much.

    If that doesn't fix it then you have no choice but to wait until the licensing terms change and your last four bills are all recalculated.  That's the third Wednesday of every month, so just hang in there.

     



  • @Buttembly Coder said:

    Last month we were setting up a pair of dev laptops, and installing the Usual Tools on them, which included Oracle 11g. Both identical machines, identical system images, identical scripts. Oracle installs on one, and crashes during install on the other three times in a row.

    You better talk to the guy next to me. He is struggling for over 3 months together with a whole bunch of sysadmins, oracle guru's and even someone from Oracle HQ to fix the problem of "slowness". We have an allocated timeslot of 10 hours, and if it gets overdue, the program gets killed and we have a problem. On the old machine it works fine with an hour to spare, the new machine however...


Log in to reply
 

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