• @Deprecated (unregistered)

    So the code seems to actually use result set fields, but not by name... and then strips off the last character. Weird.

    All fields are strings! Bonus! That will make it easy to migrate to another database.

  • (cs)
    ...the developer should have been halved
    Drawn and Quartered, at least!
  • Josephus (unregistered)

    -- define query at a high level SELECT TDate = something, ID = something, -- space(7) Reference = something, -- space(12) ... Price = something, ... FROM Detail

  • Michael (unregistered) in reply to ParkinT
    ParkinT:
    ...the developer should have been halved
    Drawn and Quartered, at least!
    "Piped" you mean
  • Doc (unregistered)

    Looks like someone once wrote the query to output delimited, fixed width columns for a printed report. Then a later developer came along and used the same query to feed the on-screen display, and no longer needed the column delimiters since the values were being stuffed into table cells - which presumably would have had their own grid styles.

    A prime example of why code re-use may be the fastest way, but not the most supportable. Sometimes, you should just re-write.

  • Anonymous (unregistered)

    Looking forward to the narration on this one. It'll be interesting to see how they handle indexed data...

    "Table data open square bracket zero close square bracket equals get substring open bracket job list rs dot get string open bracket one close bracket close bracket semi colon."

    Nice!

  • Kempeth (unregistered)

    Duh! Never heard of Pipe terminated strings?

    Very similar to null terminated strings but with support for null characters!

  • (cs) in reply to Kempeth
    Kempeth:
    Duh! Never heard of Pipe terminated strings?

    Very similar to null terminated strings but with support for null characters!

    You made me laugh in the middle of a tasty drink! I'd be angry at you if I wasn't still giggling.

  • BSDPwns (unregistered)

    "Pipe terminated strings"

    awwwww yeah.

  • (cs)

    That's Java? It looks too much like VB except for all the "let"s. Anyway, if this is the DAO layer, you're gonna have fun with the presentation layer. Yeah! Swing can make your life a living hell.

  • wtf (unregistered) in reply to ubersoldat
    ubersoldat:
    That's Java? It looks too much like VB except for all the "let"s. Anyway, if this is the DAO layer, you're gonna have fun with the presentation layer. Yeah! Swing can make your life a living hell.

    I think Artie Shaw said the same thing...

  • Whiskey, Eh? (unregistered)

    Oh, I see. The real WTF is that they should have used a loop to copy all those tableData[] strings instead of hand-writing all 31 lines.

  • (cs)

    Ceci n'est pas une pipe.

  • Tres bon, Magritte (unregistered) in reply to DCRoss
    DCRoss:
    Ceci n'est pas une pipe.
  • Carl (unregistered)

    Well, so, I saw this guy doing some amazing things on Unix, and all I remember is he used a whole lotta pipes, so I started using pipes wherever I could. It makes me feel, um, all Unixy.

  • Martijn Lievaart (unregistered) in reply to ubersoldat
    ubersoldat:
    That's Java? It looks too much like VB except for all the "let"s. Anyway, if this is the DAO layer, you're gonna have fun with the presentation layer. Yeah! Swing can make your life a living hell.

    A DAO layer? I think you mean a DOA layer!

    M4

  • (cs) in reply to ubersoldat
    ubersoldat:
    That's Java? It looks too much like VB except for all the "let"s. Anyway, if this is the DAO layer, you're gonna have fun with the presentation layer. Yeah! Swing can make your life a living hell.
    Nobody's used "Let" in VB in twenty five years. Also, the semicolons and curly braces pretty much rule out a VB-like language.
  • (cs) in reply to DCRoss
    DCRoss:
    Ceci n'est pas une pipe.
    Win.
  • Anonymously Yours (unregistered)

    It almost looks like someone clever decided to piss away some of his development time trying to format result sets the same way they come out in command line. Of course, I might just be trying to place reason where none could survive.

  • (cs)

    I can see it now. The real reason behind all this pipedness is because Once Upon A Time there was a Chief Software Architect who wrote all this application by himself. Since he didn't trust in those fancy graphical SQL tools, he wrote his own console-mode querying software. After all, graphical tools are dreadful resource hogs, filled with bugs, very limited in their functionality, and all in all just too feminine for a Real Man like him. Unfortunately when it came to displaying query results, there was just no appropriate language construct to display a separator between the cell values, so he modified the cell values to print out pretty...

    Now, as for why every query requires to select exactly 31 cells, that's a bit of an embarrassing story which will not be told here.

  • SeySayux (unregistered) in reply to DCRoss
    DCRoss:
    Ceci n'est pas une pipe.
    http://seysayux.users.sourceforge.net/cecinestpasunpipe.jpg
  • Procedural (unregistered) in reply to Kempeth
    Kempeth:
    Duh! Never heard of Pipe terminated strings?

    Very similar to null terminated strings but with support for null characters!

    Yes. And the nice thing about lpstr types is that you can have a pipe in them just by escaping them with a null.

  • (cs)

    Probably some dumb garbage that relies on the fields being returned from the database padded out with spaces, and a developer that doesn't understand fixed-width CHAR data types, ANSI padding, etc.

  • davee123 (unregistered)

    If I had to guess, I would say this was probably debug code that never got removed. Printing out the raw data in a fixed-width font would show columns of data with pipes as dividers between fields, yes? So the original dev may have been tweaking the query, and printing it out to verify it. Then, when it came time to production-ize the code, never re-wrote it to remove the pipes. Possibly because he may have wanted to print it out for future debugging.

    DaveE

  • Shriike (unregistered)
    SELECT TDate = TDate +"|", ID = "0000000"+"|", -- space(7) Reference = " "+"|", -- space(12) FROM Detail
    Now correct me if I'm wrong, but don't ID and Reference not actually return real data? ID should just return "0000000|" and reference should just return 12 spaces followed by a |.

    But I really like the comments. "Width of 7 field", or "7 spaces" was too much typing, so just "space(7)".

  • Max (unregistered) in reply to DCRoss
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

  • NetTears (unregistered)

    TRWTF is starting development with the database.

  • (cs) in reply to Shriike
    Shriike:
    SELECT TDate = TDate +"|", ID = "0000000"+"|", -- space(7) Reference = " "+"|", -- space(12) FROM Detail
    Now correct me if I'm wrong, but don't ID and Reference not actually return real data? ID should just return "0000000|" and reference should just return 12 spaces followed by a |.
    Yes, that's TRWTF... the columns come back as separate columns just like normal, but with a | at the end... and converted to strings.
  • The Emperor (unregistered) in reply to Josephus
    Josephus:
    -- define query at a high level SELECT TDate = something, ID = something, -- space(7) Reference = something, -- space(12) ... Price = something, ... FROM Dark_Side
    FTFY
  • (cs)

    I once had a nightmare of 0|1|1|1|1|1|0|0

  • fjf (unregistered) in reply to TehShrike
    TehShrike:
    You made me laugh in the middle of a tasty drink! I'd be angry at you if I wasn't still giggling.
    Don't drink and read TDWTF!
  • immitto (unregistered) in reply to Max
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    TRWTF is French.

  • ¿Que? (unregistered) in reply to Max
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    Not sure why "This is not a pipe" scores big. Am I missing something?

  • Food4Thought (unregistered) in reply to BSDPwns

    Technically there is a whole class of strings with arbitrary terminators. This allows any character to be represented in a string including nulls and pipes. The trick is that the terminator character is also placed the beginning of the string so that the parser knows which terminator character to look for in that particular string. Clever, eh? I think it's called the Minimally Efficient String Style or something...

  • Mike D. (unregistered) in reply to Vilx-
    Vilx-:
    I can see it now. The real reason behind all this pipedness is because Once Upon A Time there was a Chief Software Architect who wrote all this application by himself. Since he didn't trust in those fancy graphical SQL tools, he wrote his own console-mode querying software. After all, graphical tools are dreadful resource hogs, filled with bugs, very limited in their functionality, and all in all just too feminine for a Real Man like him. Unfortunately when it came to displaying query results, there was just no appropriate language construct to display a separator between the cell values, so he modified the cell values to print out pretty...
    I don't think it was a matter of trusting GUI tools. More likely it was a matter of never having used them and being far more trusting of printf-style debugging and logging. Debugging code and production code being the same code... I can see how a clever dev could sell that on a PowerPoint.
    Vilx-:
    Now, as for why every query requires to select exactly 31 cells, that's a bit of an embarrassing story which will not be told here.
    Probably just the maximum number of fields in the whole database. This allows code reuse or something. Yeah, it's lame.
  • Mike D. (unregistered) in reply to Food4Thought
    Food4Thought:
    Technically there is a whole class of strings with arbitrary terminators. This allows any character to be represented in a string including nulls and pipes. The trick is that the terminator character is also placed the beginning of the string so that the parser knows which terminator character to look for in that particular string. Clever, eh? I think it's called the Minimally Efficient String Style or something...
    So long as you never need more than 255 distinct byte values in a string, it's a workable idea. A length prefix removes this limit at the cost of a couple more bytes.
  • (cs) in reply to ¿Que?
    ¿Que?:
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    Not sure why "This is not a pipe" scores big. Am I missing something?

    Yes, and Google is your friend.
  • Al Burnett (unregistered)

    The developer of the pipe seperated strings apparently was using a pipe - the crack pipe!

    CAPTCHA: odio - Odio mio, this code is terrible!

  • J (unregistered) in reply to Doc
    Doc:
    Looks like someone once wrote the query to output delimited, fixed width columns for a printed report. Then a later developer came along and used the same query to feed the on-screen display, and no longer needed the column delimiters since the values were being stuffed into table cells - which presumably would have had their own grid styles.

    A prime example of why code re-use may be the fastest way, but not the most supportable. Sometimes, you should just re-write.

    First paragraph: You're probably right.

    Second paragraph: A prime example of why you don't use SQL to format for display.

  • Axl (unregistered) in reply to Max
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    Ceci n'est pas un commentaire en vedette

  • Axl (unregistered) in reply to Markp
    Markp:
    ¿Que?:
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    Not sure why "This is not a pipe" scores big. Am I missing something?

    Yes, and Google is your friend.

    Google image search is your friend.

  • inhibeo (unregistered) in reply to Max
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    It probably has something to do with embedded systems not having access to comments.

  • tation (unregistered) in reply to Max
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    Have you tried faxing the comment to the ftp site yet?

  • (cs) in reply to immitto
    immitto:
    Max:
    DCRoss:
    Ceci n'est pas une pipe.

    How is this not a featured comment yet?

    TRWTF is French.

    Have it your own way:

    http://members.cox.net/bagelhenge/pipasig.jpg

  • EngleBart (unregistered) in reply to Mike D.

    You also need to factor in Godel's incompleteness theorem when talking about string delimiters...

    My theory for this article is that the data was originally stored in a file that was migrated to a table.

  • luctus (unregistered) in reply to EngleBart
    EngleBart:
    You also need to factor in Godel's incompleteness theorem when talking about string delimiters...

    My theory for this article is that the data was originally stored in a file that was migrated to a wooden table.

    FTFY
  • bshock (unregistered) in reply to Kempeth

    The code is obviously stupid, but I've seen plenty of legacy situations that lead to this sort of thing. You start out with some sort of ancient front end that was originally written for flat files or something like that, and then a bright manager decides to add a db to it. There's no time to do things the right way from the start, so they just slide the db into place within the previous interface. Then, when better things come along, no one ever bothers to refactor the app to leverage real relational db power.

    In my last job, there was a C++ legacy app that had originally used an old version of Btrieve. A few years before, some bright coder sold management the idea of moving to SQL Server. But instead of creating a normalized db with referential integrity, he just ported the Btrieve interface to SQL Server. The thing ran incredibly slowly and required an entire day just to add one field to a table. (There were other issues as well.)

  • arrowdrive (unregistered)

    I don't know. I've seen far better ;)

    Where I work now we have an application that uses XML from a normal database. In itself not that unusual, except it runs a procedure on the database, exports the result set to a file in XML (and no it does not use SQL's ability to create the XML) then reads the file into the application....

  • (cs) in reply to luctus
    luctus:
    EngleBart:
    You also need to factor in Godel's incompleteness theorem when talking about string delimiters...

    My theory for this article is that the data was originally stored in a file that was migrated to a wooden table.

    FTFY

    Excellent, +1

  • Arlen Cuss (unregistered) in reply to Kempeth

    Only now you have to escape pipes (with nulls).

Leave a comment on “Pipe Dreams”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article