Comment On The Incrementing Bit Column

UPDATE highphilosopher SET ran = faster.

UPDATE comment SET frist=frist+1

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:

乱 - らん
Insert obligatory Kurosawa reference here.

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.)

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?

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

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!

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?

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.

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

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.

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.

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.

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.

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...

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.

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.

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.

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!

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."

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.

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.

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.

update paula
set bean = 'brillant'

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

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.

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.

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

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

Airport guy:

Hey, do you like A Flock of Seagulls?

I can see YOU do.

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?

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?

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.

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.

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.

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.

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!!!

Myabe I needing for later...

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?

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.

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")

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...

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.

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*

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

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.

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.

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

poor man's thread/access synchronization ;P