• highphilosopher (unregistered)

    UPDATE highphilosopher SET ran = faster.

  • Christopher (unregistered)

    UPDATE comment SET frist=frist+1

  • (cs)

    I tried this on SQL Server 2005, and it sets it from 0 to 1, but never more than 1.

    So, you could set it to zero, and see if anything fired that tried to update it. It wouldn't tell you how many TIMES it fired, but at least you would know your code executed.

    Sounds like debugging code that escaped into the wild. Like I've never accidentally done THAT. :eyeroll:

  • Mike (unregistered)

    乱 - らん Insert obligatory Kurosawa reference here.

  • (cs) in reply to Prosthetic Lips
    Prosthetic Lips:
    I tried this on SQL Server 2005, and it sets it from 0 to 1, but never more than 1.

    So, you could set it to zero, and see if anything fired that tried to update it. It wouldn't tell you how many TIMES it fired, but at least you would know your code executed.

    Sounds like debugging code that escaped into the wild. Like I've never accidentally done THAT. :eyeroll:

    Yep - the database equivalent of adding printf()s to your code when a debugger isn't available.

    (Presumably the coder had a reason for not just setting Ran to 1. No? Or perhaps this is RFU - the next iteration will use a full numeric field to indicate how many times it ran.)

  • highphilosopher (unregistered) in reply to Prosthetic Lips
    Prosthetic Lips:
    I tried this on SQL Server 2005, and it sets it from 0 to 1, but never more than 1.

    So, you could set it to zero, and see if anything fired that tried to update it. It wouldn't tell you how many TIMES it fired, but at least you would know your code executed.

    Sounds like debugging code that escaped into the wild. Like I've never accidentally done THAT. :eyeroll:

    You had to try this on a SQL Server. Really?

  • (cs)

    I ran. I ran until my muscles burned and my veins pumped battery acid. Then I ran some more.

  • A Nony Mouse (unregistered) in reply to Bellinghman
    Bellinghman:
    Presumably the coder had a reason for not just setting Ran to 1. No? Or perhaps this is RFU - the next iteration will use a full numeric field to indicate how many times it ran.)

    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

  • anonymous hater (unregistered) in reply to highphilosopher

    It's SQL server, you can't ever make assumptions regarding it's implementation. I'd could have been coded to do:

    • bit flipping
    • nothing at all
    • throw an error
    • ????

    All depends on the philosophy of the implementing "Architect".

    After all a: Float=double Real=float

    WTF?

    highphilosopher:
    Prosthetic Lips:
    I tried this on SQL Server 2005, and it sets it from 0 to 1, but never more than 1.

    So, you could set it to zero, and see if anything fired that tried to update it. It wouldn't tell you how many TIMES it fired, but at least you would know your code executed.

    Sounds like debugging code that escaped into the wild. Like I've never accidentally done THAT. :eyeroll:

    You had to try this on a SQL Server. Really?

  • (cs) in reply to A Nony Mouse
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

  • PITA (unregistered)

    And I ran. I ran so far away. I just ran. I ran all night and day. I couldn't get away.

  • (cs) in reply to anonymous hater
    anonymous hater:
    It's SQL server, you can't ever make assumptions regarding it's implementation. I'd could have been coded to do: - bit flipping - nothing at all - throw an error - ????

    True, in fact, I would have expected a type conversion error when trying to convert 2 to a bit.

  • highphilosopher (unregistered) in reply to Severity One
    Severity One:
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    I thought that NULL was simply a sub state of file not found.

  • Bucket of Bits (unregistered) in reply to Severity One
    Severity One:
    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    Well, that's not actually far off. 'Real' tristate logic (at the circuit level) is high / low / not connected. It isn't too hard to interpret 'not connected' as 'file not found', if you feel like it. Though null is better.

  • Todd Lewis (unregistered) in reply to highphilosopher
    highphilosopher:
    I thought that NULL was simply a sub state of file not found.

    On embedded systems where there is no file system, the one degenerates into the other.

  • (cs) in reply to anonymous hater
    anonymous hater:
    It's SQL server, you can't ever make assumptions regarding it's implementation. I'd could have been coded to do: - bit flipping - nothing at all - throw an error - ????

    All depends on the philosophy of the implementing "Architect".

    After all a: Float=double Real=float

    WTF?

    highphilosopher:
    Prosthetic Lips:
    I tried this on SQL Server 2005, and it sets it from 0 to 1, but never more than 1.

    So, you could set it to zero, and see if anything fired that tried to update it. It wouldn't tell you how many TIMES it fired, but at least you would know your code executed.

    Sounds like debugging code that escaped into the wild. Like I've never accidentally done THAT. :eyeroll:

    You had to try this on a SQL Server. Really?

    However, it's pretty common knowledge that: (value != 0) = 1

    So you really shouldn't have needed to test this one...

  • Mikkel (unregistered)

    Why is this a WTF?

    Poster doesn't say this is on production, just that the code exists - our development databases are full of short weird test procedures.

    I'd say the original developer was curious as to how the database responded and just never cleaned up - I've done the same thing a myriad of times, especially with databases where you aren't guarenteed the same behaviour between DBMS.

  • Someone like Kevin (unregistered) in reply to Mikkel
    Mikkel:
    Why is this a WTF?

    Poster doesn't say this is on production, just that the code exists - our development databases are full of short weird test procedures.

    I'd say the original developer was curious as to how the database responded and just never cleaned up - I've done the same thing a myriad of times, especially with databases where you aren't guarenteed the same behaviour between DBMS.

    Then use a temp table.

  • justsomedude (unregistered) in reply to highphilosopher
    highphilosopher:
    Severity One:
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    I thought that NULL was simply a sub state of file not found.

    No, no, no; NULL is the forth state of tri-state logic.

  • EngleBart (unregistered)

    Maybe the code was originally running on a quantum computer? That little bit could have been holding mulitple states simultaneously, including 0,1, and FNF. Adding 1 to the Qubit would change all of the states at the same instant to 1, 0, and FNF.

    What a freakin' breakthrough!

  • Engival (unregistered) in reply to md5sum

    I hope you don't make wild assumptions in your production code too. What happens here is completely implementation specific.

    For example, postgres doesn't even allow this operation, as no '+' operator exists for bit or boolean data types.

    "No operator matches the given name and argument type(s). You might need to add explicit type casts."

  • V (unregistered)

    Depending on the level of the original db designer, the original mistake could have been the wrong data type for the Ran column. I mean when I read it I thought maybe they were trying to debug how many times something ran.

    I mean it's still a WTF just of a different flavor.

  • (cs)

    That is a RWTF. I would have used:

         UPDATE Test SET Ran = 1 - Ran

    That not only allows me to set it to 1, but also 0.

  • Jack (unregistered) in reply to Coyne
    Coyne:
    That is a RWTF. I would have used: 
         UPDATE Test SET Ran = 1 - Ran

    That not only allows me to set it to 1, but also 0.

    If Ran= -1 then UPDATE Test SET Ran = Ran + 1 would set it to 0 also.

    I would have used UPDATE Test SET Ran = Ran / 0 That way I would have known it had ran when the black hole was created.

  • Paula (unregistered)

    update paula set bean = 'brillant'

  • Plz Send Me The Code (unregistered)

    if you call it an infinite number of times is it set to 1 or 0?

  • Mr Logic (unregistered) in reply to justsomedude
    justsomedude:
    highphilosopher:
    Severity One:
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    I thought that NULL was simply a sub state of file not found.

    No, no, no; NULL is the forth state of tri-state logic.

    Clearly you've never done VHDL, logic has 9 states. * 'U': uninitialized. This signal hasn't been set yet. * 'X': unknown. Impossible to determine this value/result. * '0': logic 0 * '1': logic 1 * 'Z': High Impedance * 'W': Weak signal, can't tell if it should be 0 or 1. * 'L': Weak signal that should probably go to 0 * 'H': Weak signal that should probably go to 1 * '-': Don't care.

  • The Bytemaster (unregistered)

    Who said that the column definition came before the code. Based on scenerios I have seen, it is just as likely that someone put in an incriment to store how many times something ran, however some other developer stupidly put in a test to see that the column was = 1. Because nobody wanted to touch the code itself, the column was redefined as a bit as a workarround.

    You never know which WTF came first.

  • aflockofbadcode (unregistered)

    and I ran... I ran so far away...

  • Gookey (unregistered)

    Obviously someone hasn't read up on the Therac-25.

  • Robbie (unregistered)
    Airport guy:
    Hey, do you like A Flock of Seagulls?
    I can see YOU do.
  • Chaos215bar2 (unregistered) in reply to md5sum

    Um... no. The fact that this code exists suggests it's pretty much not going to throw an error, but both overflowing to 0 and keeping the value at 1 would make sense here. There really is no way to know without looking it up for the specific implementation or just trying.

    Anyway, what is "(value != 0) = 1" even supposed to mean?

  • (cs) in reply to A Nony Mouse
    A Nony Mouse:
    Bellinghman:
    Presumably the coder had a reason for not just setting Ran to 1. No? Or perhaps this is RFU - the next iteration will use a full numeric field to indicate how many times it ran.)

    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    Naturally it's a tristate thing but seriously how often does one have to nobulate on an embedded system?

  • caper (unregistered)

    Just maybe the full meaning is

    update test_for_success set ran_to_completion = 1;

    in which case you should try to find the spot where it gets set to zero.

  • noway! (unregistered) in reply to wjr
    wjr:
    A Nony Mouse:
    Bellinghman:
    Presumably the coder had a reason for not just setting Ran to 1. No? Or perhaps this is RFU - the next iteration will use a full numeric field to indicate how many times it ran.)

    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    Naturally it's a tristate thing but seriously how often does one have to nobulate on an embedded system?
    Probably only when the internal mechanism is troubled.

  • iToad (unregistered) in reply to Mr Logic
    Mr Logic:
    justsomedude:
    highphilosopher:
    Severity One:
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    I thought that NULL was simply a sub state of file not found.

    No, no, no; NULL is the forth state of tri-state logic.

    Clearly you've never done VHDL, logic has 9 states. * 'U': uninitialized. This signal hasn't been set yet. * 'X': unknown. Impossible to determine this value/result. * '0': logic 0 * '1': logic 1 * 'Z': High Impedance * 'W': Weak signal, can't tell if it should be 0 or 1. * 'L': Weak signal that should probably go to 0 * 'H': Weak signal that should probably go to 1 * '-': Don't care.

    And here is the set of boolean logic values for my next C project.

  • (cs) in reply to Robbie
    Robbie:
    Airport guy:
    Hey, do you like A Flock of Seagulls?
    I can see YOU do.

    Those are really annoying. They fill up the parking lot outside Burger King and they are too fast for my car.

  • highphilosopher (unregistered) in reply to wjr
    wjr:
    A Nony Mouse:
    Bellinghman:
    Presumably the coder had a reason for not just setting Ran to 1. No? Or perhaps this is RFU - the next iteration will use a full numeric field to indicate how many times it ran.)

    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    Naturally it's a tristate thing but seriously how often does one have to nobulate on an embedded system?

    If you only knew the number of embedded systems on which I have nobulated!!!

  • BurgerMeister (unregistered)

    Myabe I needing for later...

  • PITA (unregistered) in reply to jasmine2501
    jasmine2501:
    Robbie:
    Airport guy:
    Hey, do you like A Flock of Seagulls?
    I can see YOU do.

    Those are really annoying. They fill up the parking lot outside Burger King and they are too fast for my car.

    Alka-Seltzer anyone?

  • Prawo Jazdy (unregistered) in reply to justsomedude
    justsomedude:
    highphilosopher:
    Severity One:
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    I thought that NULL was simply a sub state of file not found.

    No, no, no; NULL is the forth state of tri-state logic.

    Commonly known as Extended Tri-State Logic.

  • Thg (unregistered)

    TRWTF is that this makes total sense, but everyone thinks it's a WTF.

    It's more than a tsql equivalent to printf, it lets you generate reports on jobs (or whetever this application does) that did not make it to that point in the code.

    that way you can automate a re-attempt based on the results of a SQL query.

    .. or maybe I'm making a FTW out of a WTF.

    (FTW = "feck, that'll work")

  • (cs)

    Super Mario World uses this method at one point. It works, as long as you don't enter a pipe 256 times in one level...

  • abitslow (unregistered) in reply to Mr Logic
    Mr Logic:
    justsomedude:
    highphilosopher:
    Severity One:
    A Nony Mouse:
    No, no, no, NO... it is in preparation for Tristate Logic!!!

    (ps: Just remove the "NOT NULL" and have some phun!

    It's a well-established fact that tri-state logic implies 'yes', 'no', file not found'. There would have to be at least an XML file providing a translation from 0, 1 and NULL to those values. Except if it's an embedded system and it doesn't have a file system, of course.

    I thought that NULL was simply a sub state of file not found.

    No, no, no; NULL is the forth state of tri-state logic.

    Clearly you've never done VHDL, logic has 9 states. * 'U': uninitialized. This signal hasn't been set yet. * 'X': unknown. Impossible to determine this value/result. * '0': logic 0 * '1': logic 1 * 'Z': High Impedance * 'W': Weak signal, can't tell if it should be 0 or 1. * 'L': Weak signal that should probably go to 0 * 'H': Weak signal that should probably go to 1 * '-': Don't care.

    Don't know if I would go that far. VHDL has 9 states, but the resulting hardware probably doesn't.

  • justsomedude (unregistered) in reply to lolwtf
    lolwtf:
    Super Mario World uses this method at one point. It works, as long as you don't enter a pipe 256 times in one level...

    It only works if you pass up a pipe 256 times for it to work? How annoying!

    evil laugh

  • ClaudeSuck.de (unregistered)

    You come around an update statement

    It increments a bit value by one

    Now, what do you do?

    a. continue incrementing until the limit is reached :) b. upgrade to 64-bit version c. introduce three-dimensional chip and hope for the best d. understand that in T-SQL it simply swaps the between True and False

  • Yes Indeed (unregistered)

    it's just a flag toggle.

    deep in some murky unexplored crevice of a far and forgotten corner of the system lurks a code module that accesses the update statement either by reflection, or by hex-hacking, or by dark voodoo magic, and changes the + to a - based on a ui setting.

  • (cs)

    Ahhhhh the debug looks suspiciously like a Vogon DBA trying to justify their existence by planting these things accross the server (s).

    It is curious though and I am a little grateful for you that you didn't find it linking itself in a couple hundred different sub-strings, un like my own discoveries over the years.

    Just remember this: Curiousity may help understand systems, but it also can open pandora's box of Hell Code.

  • (cs) in reply to anonymous hater
    anonymous hater:
    I'd could have been coded to do: - bit flipping - nothing at all - throw an error - ????

    I expected "Throw an error". After all, in SQL Server a bit is an integer datatype that can store values in the range 0 to 1. I expected that if you put 2 in it you get an arithmetic overflow error, like you do with all the other integer datatypes.

    For it to silently stay at 1 when you put 2 in it, that's WTF-worthy all right.

    declare @SomeBit bit ; set @SomeBit = 2 ; select @SomeBit ; -- returns 1 WTF?

    I guess it is some sort of strange behaviour to make the bit datatype work more like a boolean datatype (which SQL Server does not have).

    B

  • leppie (unregistered)

    poor man's thread/access synchronization ;P

Leave a comment on “The Incrementing Bit Column”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article