• When (unregistered)

    WHEN 1 THEN FRIST

  • (nodebb)

    Someone wanted to make a statement!

    But honestly, I couldn't stop laughing just by looking at it. Thank you for this gem!

  • Darren (unregistered)

    I'm not a SQL-er, but won't this just make everything 8? 2 becomes 3, which becomes 4, which becomes 5, and so forth.

  • (nodebb)

    I'm just pleased to see that the database table uses UPPERCASE while the result set uses CamelCase and there are zero typos between the two sets of field names. It's a low bar, but they cleared it.

    Although then they spoiled it by spelling out things like DocumentType and UpdatedDate, but then went with abbreviated things like DocNmbr and CustomerNo.

    For as often as the word "number" appears in IT contexts, you'd think we'd have settled on one way to abbreviate it. You'd be wrong though.

    As to the CASE itself, I'm impressed the business rules (rule change?) are as simple as "increment by 1" in that range. I'd far sooner expected the ugly history and PHB involvement to have resulted in type 2 becomes 4, type 4 becomes 7 and type 7 becomes 2. While type 3 becomes 13 and type 6 becomes type C. Etc.

  • (nodebb) in reply to Darren

    Not at all. It's more like this from C:

        switch(h.DOCUMENTTYPE)
    {
    case 2:
        DocumentType = 3;
        break;
    case 3:
        DocumentType = 4;
        break;
    case 4:
        DocumentType = 5;
        break;
    case 5:
        DocumentType = 6;
        break;
    case 6:
        DocumentType = 7;
        break;
    case 7:
        DocumentType = 8;
        break;
    default:
       DocumentType = h.DOCUMENTTYPE;
    }
  • ichbinkeinroboter (unregistered)

    I dont feel this fix is the real WTF. Just pragmatic. As an actual real-world fix right now without tons of work? It seems solid to me.

    I want the REAL WTF that you ask the questions about...

  • ichbinkeinroboter (unregistered)

    I dont feel this fix is the real WTF. Just pragmatic. As an actual real-world fix right now without tons of work? It seems solid to me.

    I want the REAL WTF that you ask the questions about...

  • DrPepper (unregistered)

    This is a huge WTF. When you write a record into the DB you have to remember the DocumentType is a different value than the one you got back from the query. And you have to remember that for every client that connects to the DB. And that's where the bugs live.

  • (nodebb)

    My guess would be someone is trying to match an Enum in the code and they had a #2 that didn't match anything in the database.

  • (nodebb) in reply to Auction_God

    and they had a #2 that didn't match anything in the database.

    Somebody had a number two.

    Actually, I don't think this really clears the bar as a WTF. It's just some data normalisation attempt (as in making it consistent, not third normal form or whatever), but the joke was too tempting to resist.

  • Jon (unregistered) in reply to Steve_The_Cynic

    Having written my first code in 1973, it warms my heart to see the lingua franca is still C :)

  • (nodebb)

    I've seen this kind of thing a lot when you have to match data between systems, although sane peope usually create match tables so they don't have to do it on the query itself. And given the way the fields are aliased y bet that query was taken from a view, possibly querying a different database altogether.

    @Remy do you happen to have the full text of the query?

  • (author) in reply to AGlezB

    I do not. This is as submitted. I would have loved to see it.

  • (nodebb)

    TRWTF:

    When DOCUMENTTYPE returned from the database is 7, we say 8. When DOCUMENTTYPE is 8, we also say 8.

    This query demonstrates the WTFedness of wonky SQL code, the WTFedness of changing document types "dynamically" rather than "pragmatically", and it demonstrates an extremely poor example of one-to-many "relationships"

  • Jonathan (unregistered) in reply to DrPepper

    Bingo. This is creating a breeding ground for bugs. At a bare minimum, call the result of the CASE statement something like DOCUMENTTYPE_adj, or DOCUMENTTYPE_that_other_db.

  • (nodebb) in reply to Bananafish

    When DOCUMENTTYPE is 8, we also say 8

    We have no evidence that this can even happen (is 8 even valid for h.DOCUMENTTYPE?), although it does slightly worry me.

  • (nodebb) in reply to Steve_The_Cynic

    Maybe DOCUMENTTYPE set to 8 is the equivalent of redirecting to /dev/null.

  • MRAB (unregistered) in reply to When

    You're missing the incrementing.

    It should be WHEN 0 THEN FRIST WHEN 1 THEN SNECOD ELSE FILE_NOT_FOUND.

  • Joe (unregistered) in reply to Bananafish
    Comment held for moderation.
  • COBOL Dilettante (unregistered) in reply to Jonathan

    Yeah, but you just know that this query populates a view or derived table, from which countless unaccountable business users run their own daily reports.

    And at one time this derived table did indeed just contain h.DOCUMENTTYPE without edits, but then someone realised that what the business considers to be a DOCUMENTTYPE is not the same as how "h" defines a DOCUMENTTYPE, hence the edits.

    And the sane person on the team said "Shouldn't we call this BusinessDocumentType or something?" But the Project Manager said, "No, because then we would have to find every team that queries this table to get them to update their reporting SQL, and they would all make me raise a Jira ticket to put on their 18-month backlog, and we wouldn't find everyone anyway, so let's just do this."

    Granted, I've no idea what company we're talking about, but that's definitely what happened

Leave a comment on “One Case”

Log In or post as a guest

Replying to comment #694264:

Log Out

« Return to Article