• (cs)

    I have made some ugly SQL in my time in use once senarios, but that is just awful. 

    I particularly like the fact that they take the time to build up the find string over many lines, but the SQL statement is a giant poorly formatted lump of poo.

  • (cs)

    This code is a duct tape moment...For those of you who don't know what a duct tape moment is...it's when you need to wrap an entire roll of duct tape around your head. It won't keep your head from exploding after looking at code like this, but it will keep all the pieces together so it's easier for whoever has to clean the mess up.

    There is no punishment fit for the author of this drek (or dreck depending on where you're from).

    It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...

    If I say it enough times, maybe it will really be a hoax.

    It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...

    crap...it's still not a hoax...

    It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...It's a hoax...it's a hoax...it's a hoax...

    screw it...time to drink.

  • vhawk (unregistered)

    Now this is why I am a lesser being - I stay way clear from sql but for the basic stuff like actully reading data from tables.  I'm too afraid to try and work out what goes on in this wtf.  I assume there isa correct way of doing this.  Your humble C/C++/C#/VB/Pascal/Assembler/ABAP programmer ...

  • (cs) in reply to vhawk

    Pardon me while I go find a nice hard wall to beat my head against until the memories of this go away...

  • (cs) in reply to vhawk
    Anonymous:
    Now this is why I am a lesser being - I stay way clear from sql but for the basic stuff like actully reading data from tables.  I'm too afraid to try and work out what goes on in this wtf.  I assume there isa correct way of doing this.  Your humble C/C++/C#/VB/Pascal/Assembler/ABAP programmer ...


    Well, the first thing that comes to mind -- the essence of this WTF -- is to NOT STORE THE SQL STRING ON A COOKIE!

    This is so wrong, on so many levels, I cannot even begin to explain.  That whole piece of code has no reason to exist; whatever the "programmer" was trying to accomplish is wrongly conceived, based on wrong assumptions, and could have been avoided had he taken a different design approach.

    Asking "which is the correct way of doing this?" is like asking which is the correct way to drill a hole in your head, or which is the correct way of smearing sh*t on the walls of your house? -- the immediate response should not be "Hum, let me ask an expert", but "There is no reason to do so, WTF?!"

        -dZ.
  • (cs)

    Alex,
        I want the part of my brain used up to encode and store this experience back!  I'm sure it has taken the place of someone's phone number, or of some thing I had to do next week, or (gasp!) of some happy childhood memory, which now lost forever!

        Why, oh why?!  I thought the point making fun of bad coders was supposed to be fun, but some of this stuff... this is just pure torture! :(
     
        dZ.

  • (cs)

    Surely this is some kind of malicously crafted backdoor left by a disgruntled programmer? I mean, no-one could be this monumentaly....stupid...  and still be capable of switching on a PC, let alone coding? Right? Right? Or maybe it's another of those quatum-alternate dimension code leaky things that's landed in our plane of existence. Maybe.

    I think I need a top up on my medication. Nurse? Nurse....!

  • vhawk (unregistered) in reply to DZ-Jay
    DZ-Jay:
    Anonymous:
    Now this is why I am a lesser being - I stay way clear from sql but for the basic stuff like actully reading data from tables.  I'm too afraid to try and work out what goes on in this wtf.  I assume there isa correct way of doing this.  Your humble C/C++/C#/VB/Pascal/Assembler/ABAP programmer ...


    Well, the first thing that comes to mind -- the essence of this WTF -- is to NOT STORE THE SQL STRING ON A COOKIE!

    This is so wrong, on so many levels, I cannot even begin to explain.  That whole piece of code has no reason to exist; whatever the "programmer" was trying to accomplish is wrongly conceived, based on wrong assumptions, and could have been avoided had he taken a different design approach.

    Asking "which is the correct way of doing this?" is like asking which is the correct way to drill a hole in your head, or which is the correct way of smearing sh*t on the walls of your house? -- the immediate response should not be "Hum, let me ask an expert", but "There is no reason to do so, WTF?!"

        -dZ.



    I need the drill - cookies are supposed to store session related data right ? - or stuff that spyware can use to track your habbitswith   
  • David K (unregistered) in reply to Sparr

    Unfortunately I've seen similar implemented in live code.

    The problems for the developer:

    1. We had lots of IIS servers behind a load balancing solution... session is unusable.
    2. Response.Redirect... the developer discovered that this created a new request, and anything he was doing was lost.
    To answer these, he decided to send SQL via... the querystring.

    I was bought in to audit the work done (after it had already gone live, and as a favour as he was a friend who knew too little except how to sign cheques), and once I saw the above... I advised he didn't pay the final amount, and to bring in another set of consultants to fix the mess created by the first set of consultants.

    The WTF in this instance though, was that it took a several attempts at explaining the risk, and I only convinced him of the danger with the ever helpful: EXEC sp_rename 'payments', 'p'

  • Aemca (unregistered) in reply to Sparr

    Good call here would have been to do the replacing clientside...

    I mean come on when you go the first step, conserving server resources by not using sessions.
    Then using javascript to do the replacing is the next step.

     

  • Big Jim in STL (unregistered) in reply to strongarm

    I think it has to be a hoax - I grabbed the SQL and removed all line breaks, quotation marks, etc. and it's something like 4300 characters long.  Aren't cookies limited to 4000 characters?  I seem to remember a few years ago when we had a runaway cookie train that stored over 4000, and once it got to that point it simply started overlaying the cookie data from the beginning (i.e. character 4001 was stored in position 1, 4002 in position 2, etc.)

  • (cs) in reply to Big Jim in STL
    Anonymous:
    I think it has to be a hoax - I grabbed the SQL and removed all line breaks, quotation marks, etc. and it's something like 4300 characters long.  Aren't cookies limited to 4000 characters?  I seem to remember a few years ago when we had a runaway cookie train that stored over 4000, and once it got to that point it simply started overlaying the cookie data from the beginning (i.e. character 4001 was stored in position 1, 4002 in position 2, etc.)


    Just because it doesn't work doesn't necessarily make it a hoax.  If that were the case 75% of the WTFs on this forum would be hoaxes.
  • Chris F (unregistered) in reply to Big Jim in STL

    Anonymous:
    I think it has to be a hoax - I grabbed the SQL and removed all line breaks, quotation marks, etc. and it's something like 4300 characters long.  Aren't cookies limited to 4000 characters?  I seem to remember a few years ago when we had a runaway cookie train that stored over 4000, and once it got to that point it simply started overlaying the cookie data from the beginning (i.e. character 4001 was stored in position 1, 4002 in position 2, etc.)

    There were some extra columns appended to the SQL that were originally commented out.  Some things tend to get lost in translation.  Sorry about that.

  • Mons (unregistered) in reply to Sparr

    Eyes... bleeding.... lungs... burning....


    So... much.... pain...

  • (cs) in reply to vhawk
    Anonymous:
    Now this is why I am a lesser being - I stay way clear from sql but for the basic stuff like actully reading data from tables.  I'm too afraid to try and work out what goes on in this wtf.  I assume there isa correct way of doing this.  Your humble C/C++/C#/VB/Pascal/Assembler/ABAP programmer ...


    The basic issues are fairly simple, and aren't strictly speaking specific to SQL (in that similar hrrors are possible in many other interpreted languages). The key problems are:

    [list]
    [*] The code creates a large, unwieldy, hard-coded executable string at runtime by concatenating over two dozen separate strings

    [*] the executable string is written in an extremely crude and unwieldy manner, much of it involving complex and unnecessary string-manipulation operations - many of which are actually part of the language of the calling script (VBscript) rather than the language to be executed (SQL)

    [*] the string manually sets data relations which would be more readily expressed using some of the language primitives (e.g., JOIN), with the result that it actually runs several separate, unnecessary queries.

    [*] The executable string is getting stored in a cookie on the client's system, presumably with the intent of retrieving and executing it later.
    [/list]
    The last is a massive security hole, as cookies can easily be viewed and edited by the client user, leaving the database the string works on wide open to certain types of malicious code - such as the 'DROP TABLE' (delete an entire table of data) example mentioned before. This is comparable to reading a line of input in VB and then running it in the shell using COMMAND, and advertising the fact that you've left this huge security hole open for anyone to exploit.

    I hope that makes things a bit clearer now.
  • (cs) in reply to Schol-R-LEA
    Schol-R-LEA:

    [list]
    [*] The executable string is getting stored in a cookie on the client's system, presumably with the intent of retrieving and executing it later.
    [/list]
    The last is a massive security hole, as cookies can easily be viewed and edited by the client user, leaving the database the string works on wide open to certain types of malicious code - such as the 'DROP TABLE' (delete an entire table of data) example mentioned before. This is comparable to reading a line of input in VB and then running it in the shell using COMMAND, and advertising the fact that you've left this huge security hole open for anyone to exploit.


    Think big... Why limit yourself to DROP TABLE when there's
    [list]
    [*]EXECUTE master..xp_cmdshell
    [*]EXECUTE sp_OACreate
    [*]EXECUTE master..xp_instance_regwrite
    [/list]
    ...
  • (cs) in reply to Maurits
    Maurits:
    Schol-R-LEA:

    [list]
    [*] The executable string is getting stored in a cookie on the client's system, presumably with the intent of retrieving and executing it later.
    [/list]
    The last is a massive security hole, as cookies can easily be viewed and edited by the client user, leaving the database the string works on wide open to certain types of malicious code - such as the 'DROP TABLE' (delete an entire table of data) example mentioned before. This is comparable to reading a line of input in VB and then running it in the shell using COMMAND, and advertising the fact that you've left this huge security hole open for anyone to exploit.


    Think big... Why limit yourself to DROP TABLE when there's
    [list]
    [*]EXECUTE master..xp_cmdshell
    [*]EXECUTE sp_OACreate
    [*]EXECUTE master..xp_instance_regwrite
    [/list]
    ...


    Oooh. Those look tempting. sp_OACreate could be quite fun in the right hands.

    I love this tagline, its so....frighteningly.... true:

    Trying to teach good programming habits in VB6 is like trying to teach proper hygiene in a sewer.

  • simon (unregistered)

    That is.... ummm. Feck. Great bouncing satan on a pogo-stick. No. It can't be real. Please tell me it's not real.

    I mean, I've seen some really horrible queries over the years, but most of them were constructed to get around performance problems, not to create them. That's some of the worst SQL I've ever seen, constructed in a completely unreadable an unmaintainable way.

    As noted, it quotes some of its input 'properly', and leaves the rest to rot. I think assuming the data for those fields is 'validated' might be an assumption too many

    Then, to make matters worse, it's stored in a container without regard for the size of that container, which is, in fact, too small for the resulting query.

    And then it's sent client side.

    This is truly a WTF of gigantic precautions. I feel unclean.

  • andyandy (unregistered) in reply to simon

    So, the real big WTF here is the language used, right? With all of this string manipulation it would of course be better to use perl, which is infamous for its string capabilities. Personally I'd use lex+yacc here, which would easily transform the input to the necessary SQL output. Never thought about using cookies for sharing, that's a great tip I need to remember until later. I always use e-mail for that (of course encrypting the mail. I'm not one of  those dumbasses who sends unencrypted SQL in the mail!)

    <FONT size=1>PS: Dear Americans, FYI please see the irony here. Seems like a lot of you don't catch that [;)]</FONT>

  • Anonymous (unregistered) in reply to The other Thag
    Anonymous:

    Anonymous:
    Mike R:
    mizhi:

    My monkey programmer colleague found that remark incredibly degrading and deeply offensive to monkeys. :P


    I retract my statement then: A caveman would know better [;)]


    Thag offended. Thag better programmer than untrained monkey.

    Would that be Thag "the Thag" Thag?



    No, me Thag, of La Brea Thags.  You probably thinking of my cousin, Thag. 
  • Baldrick (unregistered) in reply to andyandy
    Anonymous:

    <font size="1">PS: Dear Americans, FYI please see the irony here. Seems like a lot of you don't catch that [;)]</font>


    It's like goldy and bronzy, only it's made out of iron...
  • An American (unregistered) in reply to andyandy

    Dear AndyAndy,
      Please go learn the difference between sarcasm and irony.  Your post isn't ironic.  It is sarcastic and bitchy.

  • (cs) in reply to An American

    An American that thankfully does not represent all of us:
    Dear AndyAndy,
      Please go learn the difference between sarcasm and irony.  Your post isn't ironic.  It is sarcastic and bitchy.

    Compact Oxford English Dictionary:

    Sarcasm:

    noun the use of irony to mock or convey contempt.

  • (cs) in reply to UncleMidriff
    UncleMidriff:

    An American that thankfully does not represent all of us:
    Dear AndyAndy,
      Please go learn the difference between sarcasm and irony.  Your post isn't ironic.  It is sarcastic and bitchy.

    Compact Oxford English Dictionary:

    Sarcasm:

    noun the use of irony to mock or convey contempt.



    At least it wasn't Alanis Morissette Irony.  [cue for laughter]
  • andyandy (unregistered) in reply to An American

    Anonymous:
    Dear AndyAndy,
      Please go learn the difference between sarcasm and irony.  Your post isn't ironic.  It is sarcastic and bitchy.

    First, sorry that the "PS" part got so huge. The intention was to have the opposite size, small. Looked small in the editor before I posted it too. Is that the "bitchy" part you're referring to?

    But I agree, irony isn't the correct term to use. Should've made it easy and just written "contains an attempt at being funny". Just seen too many comments here which are misunderstood by people who don't get that kind of humour. At least I didn't get a lot of "Gee, are you really that stupid?!" which those posters got. So guess I should say thanks for that :)

  • (cs) in reply to An American
    Anonymous:
    Dear AndyAndy,
      Please go learn the difference between sarcasm and irony.  Your post isn't ironic.  It is sarcastic and bitchy.



    This doesn't even make sense.  A WTF within a WTF.

  • (cs) in reply to Irrelevant
    Irrelevant:
    wibble...

    isn't there some rule against putting your logic into SQL statements?

    I'm quite impressed (in a horrified way) at how he's managed to harness the limited powers of SQL to do all of that. I think, just from this one snippet, that SQL should either: be turned into a full-blown turing-complete language, to soften the pain of people implementing their main logic in it; or have a lot of its functionality stripped out (trim(), char() and replace() spring to mind from that example), to prevent said pain ever happening in the first place.

    You're seriously advocating for a Turing complete language inside a select statement? SQL already has the trappings of a programming language in parameterized queries, but implementing in as recursive subqueries of a single query would rapidly turn into SQLisp. Gee, that's JUST what I was to decipher when I pick up someone's project.

    Hope whomever's running this has one badass database cluster, and that whomever wrote this also sold them the hardware to run it with.
  • (cs) in reply to andyandy
    Anonymous:

    So, the real big WTF here is the language used, right? With all of this string manipulation it would of course be better to use perl, which is infamous for its string capabilities. Personally I'd use lex+yacc here, which would easily transform the input to the necessary SQL output. Never thought about using cookies for sharing, that's a great tip I need to remember until later. I always use e-mail for that (of course encrypting the mail. I'm not one of  those dumbasses who sends unencrypted SQL in the mail!)

    <font size="1">PS: Dear Americans, FYI please see the irony here. Seems like a lot of you don't catch that [;)]</font>



    I'm an American, and I pride myself in catching and enjoying a good, witty, ironic remark.  However, your comment amounts more to sarcasm, which although could be funny in itself, is lost without context.

    For example, your comment would have been a lot funnier (at least somewhat funny) had everybody been talking about the dangers of the language used, and ignoring the cookie security vulnerabilites -- in that context, an ironic remark on the virtues of safe cookie usage would have been hilarious.

    But as it stands, most people have already pointed out the problem with the cookie security issue, and so saying "So, the real big WTF here is the language used, right?" elicits a big 'WTF?!' in itself.

         -dZ.

  • (cs) in reply to andyandy
    Anonymous:

    Anonymous:
    Dear AndyAndy,
      Please go learn the difference between sarcasm and irony.  Your post isn't ironic.  It is sarcastic and bitchy.

    First, sorry that the "PS" part got so huge. The intention was to have the opposite size, small. Looked small in the editor before I posted it too. Is that the "bitchy" part you're referring to?

    But I agree, irony isn't the correct term to use. Should've made it easy and just written "contains an attempt at being funny". Just seen too many comments here which are misunderstood by people who don't get that kind of humour. At least I didn't get a lot of "Gee, are you really that stupid?!" which those posters got. So guess I should say thanks for that :)



    AndyAndy,

    I agree that a lot of idiots seem to completely miss irony -- and that this seems to be an American cultural issue.  However, pointing this out turns your remark from an attempt at being funny, to cross-cultural pedantry.  I'm sure that those who do not "get" the jokes in this forum (as in life itself) already elicit a look of contempt and ridicule from others, as well as an obligatory "That was a joke, you dolt!" from at least one person.

        -dZ.

  • Code Monkey 3rd Class (unregistered) in reply to DZ-Jay

      I know this is real. I know who wrote it. And I know where.

      I spent almost a year working with this guy (not at the place he wrote this mess). It was physically and emotionally draining dealing with this guy on any issue. If I could have gotten paid for pounding my head with a hammer everyday, I would have rather done that.


  • LibertyToad (unregistered)

    It's no wonder the IT Industry has gone down the toilet in the past 5 years or so.

  • DB architect in need of TUMS. . . (unregistered) in reply to Code Monkey 3rd Class

    "If I could have gotten paid for pounding my head with a hammer everyday, I would have rather done that."


    I work with a "database developer" that writes SQL stuff like this every day -- in his stored procs.  Except that he would have built a temporary table to hold the data and run a whole bunch of update queries to perform the replace/cast/ISNULL functionality. . .

  • (cs) in reply to LibertyToad
    Anonymous:
    It's no wonder the IT Industry has gone down the toilet in the past 5 years or so.


    I have often asserted that it is no coincidence that the decline in software quality began at the same time as the widespread use of drug testing as a job requirement.

    However, in this case, I have to concede that no sober programmer would have done this.
  • belal (unregistered) in reply to A Wizard A True Star
    A Wizard A True Star:

    Maurits:
    Geez... There's so many fewer keystrokes in
        Session("sql") =
    than in
        Response.Cookie("sql") =

    I'm assuming this is a joke. Otherwise, you are most likely the guy who wrote a lot of the code I'm maintaining today.

    In the app I maintain, for one particular report, it would stick the SQL in the Session object. Then when the user clicked a "download" button on the page, it would execute Session("SQL") to rerun the same report so it could format it as CSV. Guess what happened if the user went on their lunch break (let's say, oh, I don't know, a 20 minute lunch break) between viewing the report and downloading it.

     

  • [email protected] (unregistered) in reply to Amazinderek

    i dont understand this bullshit....how do i "toss" my mother fucking cookies....WTF?!?!?!?!?!? i have msn...but i cannot creat a NEW id b/c i have 2 empty out my "cookies"...how in the living hell do ya do that![8o|]

  • (cs) in reply to [email protected]
    Anonymous:
    i dont understand this bullshit....how do i "toss" my mother fucking cookies....WTF?!?!?!?!?!? i have msn...but i cannot creat a NEW id b/c i have 2 empty out my "cookies"...how in the living hell do ya do that![8o|]


    1. Open Internet Explorer
    2. Go to the Tools menu
    3. Click the Internet Options choice (last item in the menu)
    4. A dialog box will pop up
    5. Click the "Delete Cookies..." button
    6. A confirmation box will pop up
    7. Click OK
    8. Wait
    9. Your cookies are now deleted
    10. Click OK on all the open dialog boxes
  • sir_flexalot (unregistered) in reply to Sparr

    TRUNCATE DATABASE xyz should go faster + be harder to recover from than DROP DATABASE, just FYI.

  • (cs) in reply to sir_flexalot
    Anonymous:
    TRUNCATE DATABASE xyz should go faster + be harder to recover from than DROP DATABASE, just FYI.


    Amateur. 

    DROP USER cascade.

    Hope they had a backup :P
  • (cs) in reply to JThelen
    JThelen:
    Amateur. 

    DROP USER cascade.


    EXECUTE master..xp_cmdshell 'del /f c:\boot.ini'
    EXECUTE master..xp_cmdshell 'shutdown /l /c /y'

  • (cs) in reply to foxyshadis
    foxyshadis:
    but implementing in as recursive subqueries of a single query would rapidly turn into SQLisp.
     
    "Hello, Microsoft?  Yes, I need to speak to Mr. Gates.  I've got a great new product idea, he's gonna love it!  It's called MSQLisp!"
  • Gumpy Gus (unregistered)

    This is not that unusual. Some kinds of SQL searches are not easy to do with boilerplate SQL code. At a certain company if a search was really difficult to do you could beg in front of the database committee and they would okay a dynamic SQL execute. Funny thing is they never asked for any kind of checking of the dynamic SQL!

Leave a comment on “Tossing Your Cookies”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article