🎶 He's making a list
He's testing it twice
SELECT * FROM users WHERE behavior="nice"
SQL-clause is coming
To town. 🎶

He's making a list
He's testing it twice
SELECT * FROM users WHERE behavior="nice"
SQL-clause is coming
To town.

Credit to @leeflower on Twitter

The moment when you realize you just ran a SQL update with a ';' before the WHERE clause............fml

A SQL clause walks into a bar, he sees two tables and asks: "can I join you?"

me: oh you can add a where clause to filter xxx out with your group by.

arrogant junior: whuuut? you can use where clause with group by ? No u can't!

me: err... yes you can...

arrogant junior: NO!!!! No it doesn't work that way!

me : okay okay... fine ...

**30 mins later**

i see a where clause in the sql statement lol...I don't know why this person is always so pissed and fierce lol

He’s making a database
He’s sorting it twice
SELECT * from contacts WHERE behaviour = ‘nice’
SQL clause is coming to town

I messed up carelessly in production. Learnt how SQL queries bite you in the ass when it knows you are under pressure.

Was hosting an online quiz kinda thing during my college techfest. Tens of thousands of people participating.

Using MySQL as database and thousands of queries were being executed. Everyone were pretty excited as the event just opened up.

None of the teams could solve one particular level. Turns out the solution was wrong and was asked by the organisers to change the solution for that particular level. Usual stuff, right?

Was too lazy to open up the web UI for the back office and so, straight ahead logged in to the MySQL server and ran the UPDATE query on the table consisting of the solutions.

It had been a couple of hours and the organisers came to me with a weird problem. There were no changes in the scoreboard for the last two hours. Everyone were stuck wherever they were. Weird, right?

I then realized.

Fk.

In that dreaded query, I had only run

UPDATE 'qa' SET answer = 'something'

leaving out the where clause, specifying the question to update, like

WHERE qno=13

As a result, solutions to all the questions were updated to the same answer. After hastily fixing everything back, I had the dreaded conversation.

Org: What was the problem?

Me: It was the cache.

Org: Damn thing. Always messes up.

Me: *sheepishly* yeah

Probably the most embarrassing moment in my life, wrt coding 😑

Every once in a while, execute a SQL update query on a production DB without a where clause.

Sent a fully constructed sql statement to someone expecting at least 4 rows however received reply "the result is empty" with a screenshot of empty result set from sql-developer. I kept cross-checking the where clause thinking I mixed something up.

After a few back and forth emails suddenly noticed the screenshot I received initially and I see all of the strings in where clause are lowercase. I reference my version and it is correct. When I asked her why are the strings in sql lowercase and that if she has tried the exact sql I sent in the email, the response "I didn't think it mattered what case the sql was in".

I am lost for words. The worse part is, this is someone who is supposed to go on site as part of their job and help clients setup, explain and train how the software works. This includes explaining how software intreacts with database tables 🤐

He's making a database
He's sorting it twice
SELECT * FROM contacts WHERE behavior = 'nice'
SQL clause is coming to town

I’m fucking lost.

So, situation. I have a SQL table with about 3M rows (not a lot).

I have indexes. Indexes are used. BUT when I add where clause (On indexed column), it’s super slow. Around 10 seconds.

If I do select * (ALL 3M rows) and THEN I filter then on webserver side, it takes 0.5 seconds.

HOW my manual filtering is faster than DB filtering with indexes? I even tried bubble sort. Bubble sort is faster than SQL ‘where’. HOW ?!

I do not understand….

And if I add group by….. WELL, 25 seconds SQL time. 2 Seconds if I do select all and group by in code manually.

Does not make ANY sense to me.
What am I missing ?

Wouldn't say our teamwork failed we just sucked that day.

I had a ticket to fix a SQL sp and then correct some data afterwards. As this was the typical "urgent fix need now" we went through a different process for fixing it.

Me: Just sent you some scripts can you check them over before we apply it to uat?
Boss: let's go through it together.
5 mins later
Boss: looks fine I'll apply the scripts.
2 minutes later
Me: did you apply the scripts to uat?
Boss: No I applied them to live.
Me: oh ... oh no.

At this point I realized I was missing a critical where clause so yup my update was applied against all of the data.

Boss: oh
Yup he just spotted my error.

Helpdesk phones start ringing
Boss: you pick it up it's your code
Me: hey you applied its your problem now.

One db restore and several incident meetings later we fixed it. Twas a fun day.

Even seniors make mistakes. In case you were ever doubting yourself - just remember that.

I just had a very senior level programmer on my staff add a function to a production system that issues an SQL UPDATE query without a WHERE clause. Fortunately, only the 1st entry succeeded and the rest failed due to "duplicate record" errors. Clearly he had intended to do a SELECT to check if an entry was present. If it was present, do an UPDATE, otherwise do an INSERT (think UPSERT - but done manually). However instead in the insert part they were both UPDATE's. The first update was normal looking but the second UPDATE was just this weird malformed-looking thing where he tried to do an UPDATE but to every field including the key fields. Clearly he was thinking about an insert but actually writing it as an update. Every now and then I need to remind myself that these things happen. The guy's not dumb - just made a mistake.

I'm just happy it "failed unsuccessfully".

I "failed" a SQL question once because I didn't use GROUP BY; I informed the interviewer that it wasn't needed because all the fields in the SELECT were aggregates and based on the WHERE clause I knew exactly what was being aggregated so there was no reason to echo the data value back. I continued that if there was a business or design reason for the echo then yes, the GROUP BY would be required.

copying field data from one table to another,

wondering why the execution takes so long,

since your copying only data from three rows,

realising you forgot the WHERE clause in the SQL while working on a live database and overwriting all data with the last statement 😨

Stole this from Quora from someone who stole from someone at work, who probably stole it from someone else. Now i have no idea who to attribute.

I personally don't have a funny dev sin story (not that I didn't commit any).
My internship colleague should update a value of a row in production. So he wrote a SQL command and forgot the where clause. This was the first time the company tested there rollback mechanism and it didn't work. For the next 2 weeks my colleague was busy updating 2000ish rows to make it work again

Found myself uttering profanities before the SQL update finished. I had just assumed I left out the where clause... but I didn't !

Stupidly tested some sql on development to return results for an admin (see the whole results) and stupidly didn't test the where clause for generic users (only see a subset of data)

To find out on production the where clause was being run because it wasn't a where, it was an 'and' and 'where' was not being used before so made the whole users get the entire results.

My own fault for not testing all use cases. Horrible though.

TFW you realize it's Monday, and you forgot the where clause in your SQL Statement

(22 row(s) affected)

I really love how quick it is to get data from SQL with Djangos ORM. But heaven forbid I want to do a WHERE EXISTS clause. Comparing against two tables should not be that hard....

Don't know if it's the worst, but one that's a bit pants is SOQL, Salesforce's bastardised version of SQL. Can't alias columns in a SELECT clause, can't even compare two fields to each other in a WHERE clause.