• (cs)

    WITFH??!

    I'll assume the above is a stored query.  And I'll assume PL/SQL can return a resultset from a stored proc. And-- I'll assume the author of this code needs to ease up on the cough syrup.

    Now, lets assume, for a minute, as hard as it may be to believe, given the above rumor... that PL/SQL does not return result sets from stored procs. Bizzare I know, but hear me out...

    Wouldn't it make more sense to use \t or.... even... | to delimit each field... 


    lvReturn := lvName||'|'||lvNo||'|'||lvDesc;


    Then split the thing on the | character.
  • (cs)

    I SEE the box. I just don't BELIEVE it.

  • (unregistered) in reply to Mike R

    <FONT style="BACKGROUND-COLOR: #efefef">Uhmmm... what happens when there is a '|' in lvDesc?</FONT>

    <FONT style="BACKGROUND-COLOR: #efefef"><FONT style="BACKGROUND-COLOR: #efefef"><FONT style="BACKGROUND-COLOR: #efefef"><FONT style="BACKGROUND-COLOR: #efefef"><FONT style="BACKGROUND-COLOR: #efefef"><FONT style="BACKGROUND-COLOR: #efefef"><FONT style="BACKGROUND-COLOR: #efefef"></FONT></FONT></FONT></FONT>

    </FONT></FONT></FONT>
  • (unregistered)

    this is the first one where I actually said it out loud.

  • (unregistered) in reply to

    Then use something that can't appear or escape it.
    Using any of the following symbols pretty much gurantee that you won't see them in english text: (values are 257 - 268)
    <font face="Tahoma">?, ?, ?, ?, ?, ?, •, ?, ?, ?. ?, ?

    Of course, escaping is a better solution, but if you want to do it the easy way... [pi]
    </font>

  • (unregistered)

    My eyes!  My eyes!

  • (unregistered)

    can someone please translate this into english for those of us unfamiliar with Oracle and PowerBuilder?   

  • (cs)

    Great merciful crap.

  • (cs)

    Wow .. unbelievable.  A good one.  It's been a while since we've had a classic WTF.

    Of course, I still recognize that we will soon be getting posts from defenders of this code, and those who will post even worse ideas ....

  • (unregistered)

    Oh, I see the problem. He didn't go far enough. Rather than having all those wierd character delimiters, he should have converted the whole string into an array with a numeric value for each character. That way he wouldn't have to look at all those funny box characters in his editor. That's the problem with programmers today. Why do a half-ass job when you could have easily made a complete ass of yourself?

     

  • (cs)

    That's just an ass whipping.  That's what that is.

  • (unregistered) in reply to fregas

    Ah, looks just like our company's in-house database access layer.  Written in C.  Called via CORBA from Java.  JDBC?  Nah, we don't need that....

    Only difference is we use chr(251) between fields.  [:'(]

  • (cs) in reply to

    Imagine the awesome security hole.  "Create an item with the name "blah<FONT face=Tahoma size=2>?31415?dummy" and now you can steal all the orders for item 31415."  Don't just "hope" that nobody guesses your "secret" delimiter.</FONT>

  • (cs)

    I feel the need to point out that there are several "separator" control characters defined: 0x1C: File Separator 0x1D: Group Separator 0x1E: Record Separator 0x1F: Unit Separator

    One of these would probably be a better choice than some arbitrary "character that will almost probably never appear in text". Still, you should be careful to not let it get in there by unexpected means such as what Raymond mentioned.

  • (cs)

    In fact, 0x1C should be "Field Separator", not "File Separator".

    Too much beer.

  • (unregistered)

    I actually had some code that used \b  (bell) to delimiter text once in a ASP.Net application. Didn't run well on Mono though so we had to change that function...

     

    Am I the only one having problems with the "Forget password" on this forum?

  • (unregistered) in reply to Mike R

    Mike R:
    WITFH??!

    I'll assume the above is a stored query.  And I'll assume PL/SQL can return a resultset from a stored proc. And-- I'll assume the author of this code needs to ease up on the cough syrup. 


    I have had to do this sort of thing in the past.

    Actually, it is b*!@$y difficult to get PL/SQL to return a result set, and there is no guarantee that it will actually be possible to pass it to another application (e.g. Powerbuilder).

    I could never get it to work in ODBC, although there is a rumour going around that it will work in ADO (not that I have been mad enough to try)

    (insert obligatory link to the I Hate Oracle club)

     

  • (unregistered) in reply to

    <FONT face=Georgia>yeah, how completely stupid to use a system of delimiting fields with a char...</FONT>

    <FONT face=Georgia>*cough* csv *cough*.</FONT>

    <FONT face=Georgia>but yes, this solution is quite stupid.</FONT>

  • (cs)

    If this was coded years ago, then this is not WTF'ish at all. 

    Many platforms did a very poor job of supporting some of Oracle's native data types.  In fact ADO is a prime example.  For quite awhile they had zero support for Table and Cursor (much less ref cusor) return types from Oracle.

    There's not much one can do when your DB drivers only support the most basic of datatypes.  (Well they could have used C and made direct calls against the OCI, but that's way more than I'd expect from Joe programmer).


    On a different note, MS's Oracle client implementation for .Net leaves out several of the datatypes in Oracle (variable length arrays being one of them).

    Heap

  • (cs) in reply to

    :
    Then use something that can't appear or escape it.
    Using any of the following symbols pretty much gurantee that you won't see them in english text: (values are 257 - 268)
    <FONT face=Tahoma>?, ?, ?, ?, ?, ?, •, ?, ?, ?. ?, ?

    Of course, escaping is a better solution, but if you want to do it the easy way... Pizza
    </FONT>

    Uhr, ASCII 257? WTF? Even extended ASCII doesn't go past character 255.

    These values are ASCII 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 and 12.

    I know ALT-259 gives the same result as ALT-3 on a Windows machine, but that's because they made it clever enough to modulo the input value (as long as it's 3 characters or less, seeing as ALT-0128 is the euro symbol) with 256.

    Drak

  • (unregistered) in reply to Drak

    Opps. I assumed that it works for unicdoe as well           

  • (cs) in reply to Raymond Chen

    <FONT style="BACKGROUND-COLOR: #ffffff"><FONT size=2>

    Imagine the awesome security hole.  "Create an item with the name "blah<FONT face=Tahoma>?31415?dummy" and now you can steal all the orders for item 31415."  Don't just "hope" that nobody guesses your "secret" delimiter.
    </FONT></FONT></FONT>

     

    <FONT style="BACKGROUND-COLOR: #ffffff">Please forgive my ignorance, but what exactly is the security hole there?  I can certainly see that it would jack things up all over the place, and I understand that it is a bad idea to pick a "secret" delimiter and just hope that no one discovers it, but I don't understand how doing so would allow one to "steal" data.  If someone could enlighten me, I would appreciate it.</FONT>

  • (cs)

    Translation into more sensible language:

    <FONT face="Courier New">IF lvReturn = 'z' then
       lvReturn = lvName + '`' + lvNo + '{boxchar}' + lvDesc
    End If</FONT>

    (Presumably, lvReturn is returned from the stored procedure and stored in the front end variable refl.

    <FONT face="Courier New">Name = refl.Substring(0, refl.IndexOf("`") -1);
    Number = refl.Substring(refl.IndexOf("`") +1, (refl.IndexOf("{boxchar}") - refl.IndexOf("`") +1);
    Description = refl.Substring(refl.IndexOf("") +1)</FONT>

    A more sensible person would have written this as:

    <FONT face="Courier New">int posTick = refl.IndexOf("`");
    int posBox = refl.IndexOf("{boxchar}");
    int lenNumber = posBox - posTick -1;</FONT>

    <FONT face="Courier New">Name = refl.Substring(0, posTick-1);
    Number = refl.Substring(posTick+1, lenNumber);
    Description = refl.Substring(posBox+1);</FONT>

    Of course, the biggest WTF is why anyone is still using PowerBuilder.

    <FONT face="Courier New"></FONT> 

  • (cs) in reply to UncleMidriff
    UncleMidriff:

    <FONT style="BACKGROUND-COLOR: #ffffff"><FONT size=2>

    Imagine the awesome security hole.  "Create an item with the name "blah<FONT face=Tahoma>?31415?dummy" and now you can steal all the orders for item 31415."  Don't just "hope" that nobody guesses your "secret" delimiter.</FONT>
    </FONT></FONT></FONT>

     

    <FONT style="BACKGROUND-COLOR: #ffffff">Please forgive my ignorance, but what exactly is the security hole there?  I can certainly see that it would jack things up all over the place, and I understand that it is a bad idea to pick a "secret" delimiter and just hope that no one discovers it, but I don't understand how doing so would allow one to "steal" data.  If someone could enlighten me, I would appreciate it.</FONT>

    Simple, The name comes before the number. Which, I assume is some sort of item number, Injecting the delimiter means that the next time it's read from the database, The application will think it's another number than what the name originally referred to.

    At least, that's my limited understanding.

     

Leave a comment on “The Rumor is True”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article