The Daily WTF: Curious Perversions in Information Technology

2012-01-12 Reply Admin

TRWTF is that they didn't demand a refund and sue their ass off.

I mean, I know software is not covered by warranty, but fuck, if they sell you software that literally does nothing for $7,000, and software that completely breaks down your network for god knows how many hundred thousands, the least you can do is act a bit angry.

2012-01-12 Reply Admin

Geoff:
If you are using SELECT *, and anyone changes that view/table your app is going to break. Well unless you are testing the attribute name in the record set your api returns, in which case you have accomplished nothing other than saving a few bytes in the select statement.

I've always found problems when using Sql Server (unlike DB2 and Oracle) where the data fetch calls needs to correlate in order with the SELECT field's order due to cursor issues.

Nagesh · 2012-01-12 Reply Admin

frits:
Nagesh:
That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.
Who used to own him?

Sorry for spelling mistake. You know what I mean

2012-01-12 Reply Admin

Nagesh:
You know what I mean

Yes, but do you?

Nagesh · 2012-01-12 Reply Admin

facilisis:
Nagesh:
Nagesh-fake:
Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.

That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.
Is this what passes for entertainment in India? You guys need TV!

This is not entertainment. This is highly educational program on television highliting the benefits of yoga. Fake-Nagesh is not have clue to what he's posting. Also big geography fail.

Nagesh · 2012-01-12 Reply Admin

Carl:
Nagesh:
You know what I mean
Yes, but do you?

re·nowned adjective /riˈnound/

Known or talked about by many people; famous

a restaurant renowned for its south-western-style food

Web definitions

celebrated: widely known and esteemed; "a famous actor"; "a celebrated musician"; "a famed scientist"; "an illustrious judge"; "a notable historian"; "a renowned painter"

Pim · 2012-01-12 Reply Admin

Nagesh:
Carl:
Nagesh:
You know what I mean
Yes, but do you?

re·nowned adjective /riˈnound/

Known or talked about by many people; famous

a restaurant renowned for its south-western-style food

Web definitions

celebrated: widely known and esteemed; "a famous actor"; "a celebrated musician"; "a famed scientist"; "an illustrious judge"; "a notable historian"; "a renowned painter"

Hey! You didn't state your source! You copied this without giving the proper credit! This is... this is... piracy!

Nagesh · 2012-01-12 Reply Admin

Pim:
Nagesh:
Carl:
Nagesh:
You know what I mean
Yes, but do you?

re·nowned adjective /riˈnound/

Known or talked about by many people; famous

a restaurant renowned for its south-western-style food

Web definitions

celebrated: widely known and esteemed; "a famous actor"; "a celebrated musician"; "a famed scientist"; "an illustrious judge"; "a notable historian"; "a renowned painter"
Hey! You didn't state your source! You copied this without giving the proper credit! This is... this is... piracy!

My guru say "always hide your source". He work in field of newspaper reporters.

2012-01-12 Reply Admin

And to think that this is an improvement over THIS:

http://thedailywtf.com/Articles/Hastening-an-Inevitable.aspx

bgodot · 2012-01-12 Reply Admin

In todays episode, little Bobby Tables visits the dentist...

Kuba · 2012-01-12 Reply Admin

Jay:
If not, well: "Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for." That's absolutely insane. That assumes that you create a new table for every query you write. Can you really not imagine having, say, a "customer" table, or an "employee" table, that is used in many different places in your systems?

Those things are orthogonal. I have a bunch of postgresql tables that are really views and have triggers on every insert, update and delete. They act as writeable views, but due to borkedness of oo.ORG's database front end, it won't ever let you do updates to updateable views, it will only do it to tables. Those tables are just views that take some extra disk space, that's all. They can be deleted and recreated as needed, of course when you first create them you populate them in a transaction from a bog-standard read-only yet temporary view. The tables that implement the relational, business-specific model are not directly accessible by the client, only the view tables are. This makes it easier to work around borkedness in oo.ORG (or any other database front-end).

2012-01-12 Reply Admin

Best part: the current spec sheet for Beaglesoft, err, I mean, Vulturesoft, says "Please note [Vendor's name] does not support multiple offices or locations running on a single Beaglesoft database over a wide area network.".

It's in bold on the spec sheet.

2012-01-12 Reply Admin

Weeks before D-Day:
I hope this is sarcasm....
In case it isn't, besides the horror of making views to correspond to the columns you need for every current query, your maintenance programmers will find you in your sleep and kill you if you ever need to add a column to a table.

Don't do that.

2012-01-12 Reply Admin

MyName:
Please, oh please, tell me this is a lie. Pretty please.

It's not. While I am not party to the story, I have quite a bit of dental software knowledge. And yes, "beaglesoft" did indeed work that way.

I was fortunate in my experiences in that I was able to do a full test environment prior to a similar migration, and I found the issue well before implementation day. And like the hero in the story, I was shocked at the ineptitude displayed by their development staff. I quickly burned through the sales staff, who patched me in to the developers who took the condescending tone of someone who's listening to a moron tell them how to do their job.

Mid-project, we switched to...uh...bdentrix enterprisePLUS, who's development staff actually knows how to use a database ( although back then, the software was a bit...rickety in other ways ), and never looked back.

2012-01-12 Reply Admin

Why'd he turn it down?:
Working for a company that can sell a plug and play USB camera for $7,000, and they'll think I'm a technical deity for being not incompetent?
Seems like it could be fun.

This is pretty much par for the course for a place that sells medical equipment. You can mark up crap devices to them so much it's freaky. And I haven't seen one yet that does a good job. Definitely a good market to be in.

2012-01-12 Reply Admin

anonymous:
i don't get it. what's a "where clause"?

more importantly .. WHERE is the CLAUSE?

2012-01-12 Reply Admin

Tud:
TRWTF is that they didn't demand a refund and sue their ass off.
I mean, I know software is not covered by warranty, but fuck, if they sell you software that literally does nothing for $7,000, and software that completely breaks down your network for god knows how many hundred thousands, the least you can do is act a bit angry.

Looks like this was back in the day when EULAs did not have an anti-lawsuit clause.

2012-01-12 Reply Admin

I have had the (dis)pleasure of working with (B)Eaglesoft in Los Angeles. Sadly, based on my experiences, I completely believe this story.

2012-01-12 Reply Admin

Have you got a short version of the story?????

Cassidy · 2012-01-12 Reply Admin

mrfr0g:
@Ross
It was typical to see pages that started with;

SELECT * FROM Table1 SELECT * FROM Table2 SELECT * FROM Table3

... SELECT UserID from Table1

Of course he didn't use the where clause, instead he used a for loop to find the user he wanted. And yes, the tables were named, Table1 - 26.

Often applications developers are not database developers, and unfortunately many coders learn enough SQL to extract data from the database then choose to manipulate it in code, rather than use database functionality (which is often faster and more efficient).

Happens way too often...

2012-01-12 Reply Admin

Wow, what a complete load of crap. Sounds like someone from (B)dentrix submitted a bogus story and TDWTF bought it.

2012-01-12 Reply Admin

Steve The Cynic:
Cantabrigian:
> The system had completely grinded to a halt.
I finded that a strange sentence.
bind -> bound find -> found wind (long 'eye' sound) -> wound grind -> ground

but

blind -> blinded mind -> minded (your own business) wind (short 'i' sound) -> winded (usually only in passive voice)

It's English that you should find strange.

I finded English Very Strange

Captcha: commoveo - How did they know my hair was just a commoveo

2012-01-12 Reply Admin

Shutterbug:
Anyone else noticed that Nagesh appears to have got a new camera for Christmas?

Didn't realise he was Head Photographer, New York Times (Asia Office)

tweek · 2012-01-12 Reply Admin

Cassidy:
Often applications developers are not database developers, and unfortunately many coders learn enough SQL to extract data from the database then choose to manipulate it in code, rather than use database functionality (which is often faster and more efficient).
Happens way too often...

Oddly enough, that was my comment in my staff meeting today. "Well, other than [Vendor] needs a good dba to make their database ... relational, I don't have any real issues with them."

Sometimes I think the system we use was sketched on the back of a napkin ... and runs only because computers have become powerful enough that we don't complain.

Kuba · 2012-01-12 Reply Admin

Nagesh:
My guru say "always hide your source". He work in field of newspaper reporters.

Wow. They've got so many, they have whole fields of them!

2012-01-12 Reply Admin

No test migration is the REAL WTF.

2012-01-12 Reply Admin

First chapter of SQL for Dummies. Didn't bother reading the rest. The saddest thing is that I know exactly what software they're talking about... and my dentist also uses it.

2012-01-13 Reply Admin

Bananas:
Richard:
Mike:
One time I wrote: SELECT * from TEETH but forgot the: WHERE CAVITIES > 0
...so now I have to drink my food.

At least it wasn't

DELETE FROM TEETH;

At least it wasn't
TRUNCATE TABLE TEETH;

Or...

INSERT INTO teeth (o, m, g) SELECT bumper AS LargeBluntObject FROM 1963_Cadillac WHERE speed = '90mph' AND girlfriend = 'pissed';

2012-01-13 Reply Admin

Don't make fun of dentists, many are victims of their own toxic amalgam fumes.

2012-01-13 Reply Admin

What's with that stupid long name for a dentist's office? "I am going to my dentist today."

"Who?" "Um, let's see ... Rutherford, .. um ..., Atkinson, no wait, it's Rutherford, Price, .. well, sorry I forgot. Let me look it up. I will send you a text message."

Keep it short dumbos, and put your ego into the nearest waste paper basket. Your name doesn't need to be written on every little shit that you do.

Severity One · 2012-01-13 Reply Admin

MojoMonkeyfish:
I wouldn't say that. Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for. That means, there shouldn't be any superfluous columns you need to filter out.
The job I'm currently working is all CQRS/EventSource, so there's pretty much a 1:1 correspondence between use cases and tables.

As a very database-centric developer for most of my career, it took some adjustment, but it's an exceptionally fast and scalable model.

Anyhow, all our "production sql" is "SELECT *", and it hasn't been an issue for us at all.

When writing down something like this, you should ask yourself: "Why did they invent SQL in the first place?"

In general, when you're doing something that apparently nobody else has done before (like deciding that Java's Exception and Error are not enough, and that you need a new derived class or interface from Throwable), you should take a step back for a second and wonder why exactly nobody has done it before.

Mind, I agree that views should be used whenever possible and useful, and that far too much is done by hard-coded SQL queries in applications. I believe that, as much as possible, views, stored procedures and stored functions should be used.

However, if you create a view for each and every query, your database becomes a bit messy. Moreover, you create a dependency between your database and your application, because you rely on an exact order and amount of fields being returned from a query. It's not so easy to change a table and mess up a SELECT * query; it's very easy to change a view and do exactly that.

So I think your firm should look critically at the way you do your queries. Because what you describe is a major WTF.

2012-01-13 Reply Admin

Oh come on! 'Irregular verbs' (from once existing verb-classes) are common in many european dialects.

2012-01-13 Reply Admin

Richard:
MojoMonkeyfish:
Anyhow, all our "production sql" is "SELECT *", and it hasn't been an issue for us at all.

An advantage of specifying the column names is that you may detect bugs quicker and you may make the system more robust, especially if you index the returned result set by column number not name.

An advantage of selecting * in some environments is less code change if you add fields, but the environments I work on use an object relational layer so I don't actually end up typing this stuff in production code, and things are more nailed in anyway.

SELECT * interactively, when exploring a database, is great though.

Yo don't go dissin' selectstar .. it rocks.

IF you application is somewhat hardcoded at some point, you need to select specific rows according to the hardcoding you just did.

BUT for anything that is meant to be abstract and generic (and the more things are, the better), select * is the best solution.

Of course, not knowing SQL (i.e. not using WHERE, joins, stuff or using MySQL5+ innoDB or worse) is a crime.

2012-01-13 Reply Admin

Jay:
MojoMonkeyfish:
Any supposedly production SQL that starts 'SELECT *' is bogus.

I wouldn't say that. Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for. That means, there shouldn't be any superfluous columns you need to filter out.

The job I'm currently working is all CQRS/EventSource, so there's pretty much a 1:1 correspondence between use cases and tables.

As a very database-centric developer for most of my career, it took some adjustment, but it's an exceptionally fast and scalable model.

Anyhow, all our "production sql" is "SELECT *", and it hasn't been an issue for us at all.

I'm hoping this is a troll.

If not, well: "Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for." That's absolutely insane. That assumes that you create a new table for every query you write. Can you really not imagine having, say, a "customer" table, or an "employee" table, that is used in many different places in your systems?

He's just addicted to views .. those can be cool but are of course better used only for known specific cases.

i.e. you always query employee + appointment + teeth in the same fashion, so: -> build a view (materialized if required for speed, depends on the case) -> query it instead of keeping complicated queries

This helps simplifying the application AND because you have the info at the lowest level, you can both speed up things (materialized, other optimizations, updatable view) AND have a unique source of truth at the lowest possible level, which is extremely nice when you need to change GUI's / create API's / etc.

2012-01-13 Reply Admin

Tonsil:
Trolls notwithstanding, one thing about the SELECT * approach to keep in mind: If you are joining multiple tables with one or more identical column names, the results could be unpredictable, depending on how your software handles it. For example, if the result gets dumped into a hash, perhaps the last distinctly named column is stored. If the tables' structures change, this could affect the code.

In such crappy old software, I'm willing to bet 50 internet-dollars that column names go as such : patient(p_id,p_name,p_firstname,...)

Thus a select * join would not be an issue.

But ... in this case, it's quite clear that the joining was done in the application, for further advanced madness points.

2012-01-13 Reply Admin

Mainframe Web Dev:
Geoff:
If you are using SELECT *, and anyone changes that view/table your app is going to break. Well unless you are testing the attribute name in the record set your api returns, in which case you have accomplished nothing other than saving a few bytes in the select statement.

I've always found problems when using Sql Server (unlike DB2 and Oracle) where the data fetch calls needs to correlate in order with the SELECT field's order due to cursor issues.

That's probably an older SQLServer version, haven't seen that in the decent ones (2005+).

Either way .. why use SQLS when you could be using postgreSQL for free and better results --

2012-01-13 Reply Admin

Kuba:
Jay:
If not, well: "Ideally, if you're querying, it should be from a view or table that is built specifically for the purpose you are querying it for." That's absolutely insane. That assumes that you create a new table for every query you write. Can you really not imagine having, say, a "customer" table, or an "employee" table, that is used in many different places in your systems?
Those things are orthogonal. I have a bunch of postgresql tables that are really views and have triggers on every insert, update and delete. They act as writeable views, but due to borkedness of oo.ORG's database front end, it won't ever let you do updates to updateable views, it will only do it to tables. Those tables are just views that take some extra disk space, that's all. They can be deleted and recreated as needed, of course when you first create them you populate them in a transaction from a bog-standard read-only yet temporary view. The tables that implement the relational, business-specific model are not directly accessible by the client, only the view tables are. This makes it easier to work around borkedness in oo.ORG (or any other database front-end).

What do you call a database front-end, and WTF do you need one ?

Also .. using fake views in a DBMS that supports real views is scary. You get 5 extra internet-points for that.

2012-01-13 Reply Admin

Cassidy:
mrfr0g:
@Ross
It was typical to see pages that started with;

SELECT * FROM Table1 SELECT * FROM Table2 SELECT * FROM Table3

... SELECT UserID from Table1

Of course he didn't use the where clause, instead he used a for loop to find the user he wanted. And yes, the tables were named, Table1 - 26.
Often applications developers are not database developers, and unfortunately many coders learn enough SQL to extract data from the database then choose to manipulate it in code, rather than use database functionality (which is often faster and more efficient).

Happens way too often...

Way too true .. and since today many failwebdevs (even ... worse than regular faildevs) are considered as coders, the problems worsen every day (yes, many of those think MySQL MyISAM is a decent database ... and the more advanced think MySQL InnoDB is ACID compliant .. f'ing noobs.

Unfortunately, their overlords don't understand anything and fail to see the point of having a "DBA" - or even just a guy who actually understands the meaning of the following words :

RDBMS,ACID,Transaction,FK,JOIN,VIEW,INDEX,TRIGGER

Really ridiculous to see how short a list would be enough to avoid so much failure ...

2012-01-13 Reply Admin

Tom:
I have this marvelously flexible language called Perl. You can "SELECT *" into a hash, which will automagically create a hash entry for each column. Then your code can say things like:
if $att{price} > 10 ...
If the new attributes are added to the table, you don't have to modify any code. It is even update-safe.
$att{status} = 'x';
$att{date} = $Today;
Then you can write the whole row back and the hash is transformed back into a row again. Otherwise you'd need to do separate SQL updates for each attribute?? What a pain!

Haha, nice try. Everyone knows that if you're going to be pissing about with databases and Perl hashes, you'll be using KiokuDB and not SQL.

Object databases FTW, if only because the vast majority of coders seem unable to understand SQL and relational database architectures.

Yazeran · 2012-01-13 Reply Admin

Ru:
Tom:
I have this marvelously flexible language called Perl. You can "SELECT *" into a hash, which will automagically create a hash entry for each column. Then your code can say things like:
if $att{price} > 10 ...
If the new attributes are added to the table, you don't have to modify any code. It is even update-safe.
$att{status} = 'x';
$att{date} = $Today;
Then you can write the whole row back and the hash is transformed back into a row again. Otherwise you'd need to do separate SQL updates for each attribute?? What a pain!
Haha, nice try. Everyone knows that if you're going to be pissing about with databases and Perl hashes, you'll be using KiokuDB and not SQL.

Object databases FTW, if only because the vast majority of coders seem unable to understand SQL and relational database architectures.

Well not necessary, If you use the DBD interface you can use perl as a frot-end for almost any database (we use it for postgresql). The advantage of using hashes for storing records retrieved is that if you change the order in your SELECT statement, the rest of the record processing code does not need to be updated.

Granted the specs for fetchrow_hashref() states that it is slower than fetchrow_array() which for some applications may be significant, however in most cases taking small hit on performance for a large gain in maintanability is worth it.

Yours Yazeran

Plan: To go to Mars one day with a hammer.

2012-01-13 Reply Admin

Yazeran:
Ru:
Tom:
I have this marvelously flexible language called Perl. You can "SELECT *" into a hash, which will automagically create a hash entry for each column. Then your code can say things like:
if $att{price} > 10 ...
If the new attributes are added to the table, you don't have to modify any code. It is even update-safe.
$att{status} = 'x';
$att{date} = $Today;
Then you can write the whole row back and the hash is transformed back into a row again. Otherwise you'd need to do separate SQL updates for each attribute?? What a pain!
Haha, nice try. Everyone knows that if you're going to be pissing about with databases and Perl hashes, you'll be using KiokuDB and not SQL.

Object databases FTW, if only because the vast majority of coders seem unable to understand SQL and relational database architectures.
Well not necessary, If you use the DBD interface you can use perl as a frot-end for almost any database (we use it for postgresql). The advantage of using hashes for storing records retrieved is that if you change the order in your SELECT statement, the rest of the record processing code does not need to be updated.

Granted the specs for fetchrow_hashref() states that it is slower than fetchrow_array() which for some applications may be significant, however in most cases taking small hit on performance for a large gain in maintanability is worth it.

Yours Yazeran

Plan: To go to Mars one day with a hammer.

"If you change the order in your SELECT statement"

Right .. like how does your application rely on that ??? Seriously .. wtf. especially since you mention fetchrow_array, your indices would not be numeric, and thus reordering wouldn't change a thing --

I don't see how an application relying on the order of a SELECT statement can be considered NOT a WTF.

As a summary, using stupid solutions to fix stupid problems does not count as doing the right thing.

2012-01-13 Reply Admin

Nagesh:
Nagesh:
Here in Hyderabad, we are also having dentist problem. He is traveling acros cuntry avalible in Hyderabad only cupl of days out of the year. He is also demand brakes after each visit.
[image]

That is Baba Ramdev, reowned Yoga Guru! Stop making fun of noted celebrities.

Is that what passes for Yoga in Indian? Man, you guys do everything half-assed.

PedanticCurmudgeon · 2012-01-13 Reply Admin

AdT:
Don't make fun of dentists, many are victims of their own toxic amalgam fumes.

There may be some truth to that. I read somewhere that extra amalgam has to be disposed of as hazardous waste. But it's OK to put in our mouths. Go figure.

2012-01-13 Reply Admin

bgodot:
In todays episode, little Bobby Tables visits the dentist...

I don't understand this, is it a reference to something I don't know about?

2012-01-13 Reply Admin

No, no it isn't.

(It's a reference to something you DO know about.)

Kivi · 2012-01-13 Reply Admin

BlackKnight:
bgodot:
In todays episode, little Bobby Tables visits the dentist...

I don't understand this, is it a reference to something I don't know about?

No.

2012-01-13 Reply Admin

NEW ARTICLE ON DAILY - YEEEHAAA

Arancaytar · 2012-01-13 Reply Admin

Quicksilver:
The Dentist. The arch-foe of any geek out there! Especially of those who create their own companys and give out shares!

Your username references the wrong book. :P

2012-01-13 Reply Admin

They probably also have to dispose of the rise water as hazardous waste.

operagost · 2012-01-13 Reply Admin

toothdecay:
Best part: the current spec sheet for Beaglesoft, err, I mean, Vulturesoft, says "Please note [Vendor's name] does not support multiple offices or locations running on a single Beaglesoft database over a wide area network.".
It's in bold on the spec sheet.

So Patt... I mean Beaglesoft still doesn't know how to do use SQL properly-- 8 years later.

Classic WTF: Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc

Leave a comment on “Classic WTF: Rutherford, Price, Atkinson, Strickland, and Associates Dentistry, Inc”