• Onur BIYIK (unregistered)

    @P514 is used as task type. That's the real WTF here.

  • Anonymous Coward (unregistered) in reply to ParkinT

    Oh my god, the original programmer did 9/11!

  • John (unregistered) in reply to Mason Wheeler

    You have to parse it before you can optimize....

  • Hans (unregistered) in reply to EatenByAGrue
    EatenByAGrue:
    Rule of Upper Limits: if you have to ask what the upper limit is, you're probably doing it wrong.

    That's bullshit. Simple example: I wrote an application that feeds industrial data into a presentation tool for industrial data. In a single session, there will be hundreds of millions of values - yet the presentation tool crashes if you feed it more than 2^16 in one shot.

    There is no indication in the API that such a limit might exist (the "number of values" field is a 32-bit integer!), nor in the documentation, and the application is being sold for specifically this purpose, yet the upper limit bit me anyway.

    That same application crashes when you feed it more than 3000 channels of data, despite claims of the manufacturer to the contrary.

    I've worked with an OPC server that fails when you request more than 128(?) channels. On a machine that acquires about 15,000 of them.

    I've worked with a GPIB device that won't allow you to join queries, because any two queries together produces an answer that is too long for its tiny brain (which is apparently limited to maybe a hundred bytes or so).

    So yes, we very much DO want to know what the upper limits are. Because some of us write applications that do not sit within the comfort zone of the manufacturer, but rather try to push the limit of what is possible. And it is a lot nicer to do so while well-informed, than through trial and error.

  • (cs)

    This looks like a compiled statement from an application. I dunno how it generally goes, but I work with applications that connect to SQL server, and most of the time when playing with server-side problems, we have to debug stuff like that.

    Basically when you tell a C# or whatever application with a query builder to get this and this, it might go a bit overboard with into variables and parentheses.

    However, it's completely plausible that the original SQL query was very close to what we have here. But since it's been recompiled by the server, we don't really know ;)

  • M (unregistered) in reply to Hans
    Hans:
    EatenByAGrue:
    Rule of Upper Limits: if you have to ask what the upper limit is, you're probably doing it wrong.

    That's bullshit. Simple example: I wrote an application that feeds industrial data into a presentation tool for industrial data. In a single session, there will be hundreds of millions of values - yet the presentation tool crashes if you feed it more than 2^16 in one shot.

    There is no indication in the API that such a limit might exist (the "number of values" field is a 32-bit integer!), nor in the documentation, and the application is being sold for specifically this purpose, yet the upper limit bit me anyway.

    That same application crashes when you feed it more than 3000 channels of data, despite claims of the manufacturer to the contrary.

    I've worked with an OPC server that fails when you request more than 128(?) channels. On a machine that acquires about 15,000 of them.

    I've worked with a GPIB device that won't allow you to join queries, because any two queries together produces an answer that is too long for its tiny brain (which is apparently limited to maybe a hundred bytes or so).

    So yes, we very much DO want to know what the upper limits are. Because some of us write applications that do not sit within the comfort zone of the manufacturer, but rather try to push the limit of what is possible. And it is a lot nicer to do so while well-informed, than through trial and error.

    Whoa there, Tex! Back up and read the word 'probably' in the original post.

  • (cs) in reply to frits
    frits:
    C is the de facto language of real time apps, so your instincts were correct. Many vendors supply C++ compilers as well, which is what I prefer. Real-time graphics are used for electronic instruments such as digital oscilloscopes, spectrum analyzers, and other equipment that have to display transient and dynamic signals.

    I know and knew C is frequently used in real-time apps. Both of the real-time systems I've worked with pushed a different language as the vendor-preferred customized coding language. The only advantage I recall them having over C was they handled memory allocation automatically. But I have a recollection that they both used a lot of static allocations with bounds checks, rather than dynamically allocating.

    It makes sense that some electronic instruments would use real-time graphics, now that you mention it. However, the only one I'd ever gotten past the shiny (well, matte-finish) exterior to see how it was coded did not.

  • Anonymous (unregistered) in reply to TarquinWJ
    TarquinWJ:
    I assume Ben just removed all ( and ) characters in the WHERE clause, and used them to build a Lisp app that commands a robot to slap the original developer.

    There's nowhere near enough parenthesis there to make a Lisp program.

  • Anonymous Coward (unregistered) in reply to Anonymous

    But apparently enough to make an ASCII robot, so close enough.

  • odistine (unregistered) in reply to LU
    LU:
    This made me actually say "What Da F**k" out loud...
    Really? Most people prefer shorter words than "FasteriskasteriskK"..
  • Chris (unregistered) in reply to Rob

    That was my first thought.

  • Patrick (unregistered)

    That was pathetic. It only needs brackets for the parameter on the count function. All of the others - that means ALL of the others - are superfluous.

  • Sampo Syreeni (unregistered)

    Let me get this straight. Somebody got the fact that conjunction is associative for the first couple of lines...and then snapped?

  • pstickne (unregistered)

    Unfortunately I have run into that error message when using Microsoft SharePoint and CAML (XML) queries. CAML does not allow "advanced" SQL operations like IN or sub-SELECTs (the entire CAML query is one very primitive form a WHERE clause). The solution? Lots and lots of nested CAML '<OR>' tags which is turned into a gibberish like the SQL shown.

    And yes, the CAML to do that is generated automatically.

  • Sekhar Maitra (unregistered)

    This is painfull. How many tylanol or alive did you take!!!!!!!!!

  • ParseMaster (unregistered)

    I don't know which is the larger WTF...

    The generated query or the completely broken SQL parser?

  • chiming.chin (unregistered)

    I think that the SQL was generated by Excel and had not any usefulness.

  • ... (unregistered) in reply to bunnyman
    bunnyman:
    Anyone who can create code with so many left parens without making an ASCII art fish is missing the point. 
        
            ((
(       ((((((((((
 ((  (((((((((( ((((
 ((((((((((((((((((((
 ((  (((((((((((((((
(       (((((((((( 
             ( (

    That's not even close to the 511 in the code sample. It could be so much better.

    Dang!!! Here i am with my ascii-art "cape canaveral with rocket, control-room-bunker, exhaust vent and sud-patches". And then he comes along with that fish!

    Captcha: causa Alex's captcha system is weird.

Leave a comment on “SQL Error 191: Nested Way Too F#%&ing Deeply”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article