In general, the real lesson learned is that unless its something of strategic importance, there is NO gun barrel touching your head. Work will be always there. It never stops. Your life on the other hand, does end, eventually. So, screw it, weekend is weekend.

@@PhilipAlexanderHassialis Yeah, weekend is important to have time for yourself and family. A lot less stressful to fix problem if you have your team mates present and everyone is aware that some changes are happening as well.

@@PhilipAlexanderHassialisyeah, that's one of the most hard things I've learned owning a company is that work NEVER stops. YOU need to stop.

​@@PhilipAlexanderHassialisheh definitely the case in most software. I'm just a hobbyist programmer but in my medical career although there's never a gun to my head on the weekend, there may well be one for a patient! Physicians getting the time and resources to live their lives while still covering patient needs is entirely systemic. It may be the same in some safety or security critical software work.

Yuuuuuuuuuuuuuup... Never, ever, _ever_ do a Major Thing on Friday afternoon (bonus points if that's 5 PM and you leave work at 6... uber points if that's 5:55 PM xD). Just NO. I had to learn to say "Dude BossMan, NO - this will explode somehow, and Friday at 5:30 PM is NOT the time to do it. Let's look at it with fresh eyes on Monday."

Unless he's got autocommit set to true. Then it treats all queries as individual transactions. So technically no ROLLBACK.

@@conceptraton production connections this disabled by default

Really? I had configured mine just for the red boarder and confirmation text, had no idea it also automatically wrapped everything in a transaction! (Of course, prod connections are exclusively readonly in my company....but still)

@@DeadmanstrollnSure, connection types are configurabled - in Window/Preferences/Connections/Connection types - it has option "auto commit by default", i disabled it for my production connections so i have manual transactions

I know it's 1 month late, but you beat me to it.

This is such a pro feature and saved me before, and changing the whole UI theme based on what DB the command/window is running on is also very powerful (red - production, green - qa, normal grey - dev)

@@MatthewSwabey he means pro as in "good" dbeaver is completely free and its quite awesome :)

😂 that's the right call.

Ironic lack of transaction hopefully? 😂

@@Kane0123 can't rollback the gone weekend :C

you forgot to add to the where OR 1=1 :)

Literally my first thought. I never understood "oh, it's easier, you don't have to type semicolons anymore", no, NO, keep the syntax a bit tedious, put a little speedbump in the train of thought, thank me later.

I don't get why it would ever think that a blank line means the end of the query. That seems like a really bad design. Even e.g. mssql, which does not need semicolons, does not do this. For postgres, just use psql. If you leave a blank line, nothing happens. If you forget the semicolon, nothing happens. You add the semicolon and then it runs.

@@georgehelyar agreed. My company uses beekeeper and it separates using semicolon. If two queries are separated by a newline, it throws a malformed query error but never does shit like "executing partial query because I think new line means end of the query"

what's the point of the semicolon if the parser can't be bothered to fail when the friggin semicolon is missing all right?

tldr: if the semicolon is optional, the semicolon is useless (in this particular scenario)

A try catch would have done nothing. It was a singular statement that didn't fail.

​@@toabthis has a begin transaction with the commit transaction commented out and a rollback in place. The try catch is probably there in case a udf or stored procedure called blows. This execute once but roll it back so effected row counts can be checked, then enable the commit is a very common pattern (when live running Sql in prod)

​@@goraxe01 don't run things that "blow". That is some junior level space brain right there. More importantly, the amount of production code many places use that read dirty isn't zero. Do you understand why intentionally pulling a "haha just kidding" with data has the potential to cause issues? Yeah in a perfect world everything only ever reads committed data. We never inherit perfect worlds, and the last guy was always the world's biggest dummy.

Fortunately, in the case from the video, Postgres doesn't allow dirty reads, but yes this is true you need to know and set your isolation levels. To add to the "should have turned on Dbeavers production environment option", when you do that it flashes a big warning about the operation not having a WHERE clause, which would also have saved them.

It's a tough one for sure. In general I feel like the feelings of the person being given feedback to are not a good gauge for feedback quality, at least in the very moment. Sometimes the feedback has to make you feel bad in order for you to grow as a person, but as you said some people are so unprepared for handling that kind of feedback that they learn to avoid the risk altogether (your drowning analogy) instead of learning from the experience. At the very least total conflict avoidance can easily be much worse than going a bit overboard with the criticism. Someone has to be able to talk about the elephant in the room, and hopefully your manager is a person who can do that when it's necessary. This is partially a culture-fit issue too and it should not be taboo to acknowledge that not everyone is suited for every type of job or situation. Ideally the environment would support growing a healthy mindset for both how to receive feedback and how to give it. I do agree with prime here that nowadays the scales seem to tip way too much in the territory of conflict avoidance which lets issues fester rather than being addressed. Addressing mindset issues can be very uncomfortable and the average person probably does not enjoy making others uncomfortable, so it's easy to see why this'd be the case. There are so many stories online of bosses who pretend that everything is fine & give "positive" feedback to an employee, only for the employee to be fired "out of nowhere". This is exactly the kind of conflict avoidance that's bad for everyone involved. Personally I try to focus on being truthful, fair, and compassionate but also to not avoid conflict or giving feedback which would make others uncomfortable if there's a real issue. Conflict is much better than no communication at all.

Still, sometimes things might go unnoticed, and right after the query is ran it goes to brain like a lightning that you did x,y,z wrong. It's almost like brain knows you are going to f up, and waits until it happens, then tells you.

Agreed. SQL desperately needs replacing with better RDBMS language that implements the 40 years of experience we have with DBs...

You can still have the same issue unless the where clause is required.

@@TehKarmalizer Which I think it should be (and I realize we have the benefits of decades of hindsight). `UPDATE orders SET is_deleted = true` with no WHERE clause should either be an error or match *nothing*, not *everything*. I think that makes way more sense, both in terms of safety and semantics. To me, an UPDATE with no WHERE is an incomplete statement. Imagine if the engine was a human assistant: if given the query above, a good one would ask for clarification: "Which records?" Not just assume all. If you actually *do* want to update everything, at the very least require that explicit declaration in SQL-speak: `WHERE true`.

@@TehKarmalizer imagine the where clause being required, but the AI auto-completing with `where 1=1` 😂

Foreign keys save your ass sometimes tho gotta love em :)

Who would give a jr dev prod access day 1?

@@xeridea The same guy who would use actual prod credentials as example for setting up a test db

Seriously, nobody can blame your colleague. The entire process is fucked up.

There was no process, and many companies still operate like this today which is the insane part of it

Scared to the point of paralysis isn't necessarily a bad thing. If there are safeguards that could be there, but aren't, it's usually pretty wise to just put the safeguards in place. Little bit like handling a gun with the safety off. I know I'm safe enough with firearms that it's very unlikely to actually go off, but I'm still gonna insist that the gun has a safety latch because a lack of safety just isn't necessary.

This is probably one of the scariest IT things I've ever read..

@@trashmail8I know a bank that does this, but they take a backup/snapshot/diff/delta every 15 minutes and a milestone every 3 hours. Meanwhile some guy in a dungeon is deleting and updating rows from the main database. Insanity.

Could you please share a sample query for both ways of doing it, to better illustrate what you're talking about?

Also, using EXPLAIN would probably have helped to see the error instantly. But yeah, I also thought it was lacking a transaction, and I don’t know shit about SQL.

@@nchomey You start with "BEGIN;" and then execute the query you want. If you realize something went wrong (based on number of rows affected for example) you simply type "ROLLBACK;'". If you are satisfied with the results then you type "COMMIT;".

this is exactly the right way to do it. but, i even avoid writing these scripts if i can, by using the database editor to edit records manually

@@nchomey i hope this helps. it's an example for Microsoft SQL Server (using Management Studio): BEGIN TRANSACTION; DELETE FROM Employee WHERE DepartmentID = 13; ROLLBACK; -- cancel changes then it automatically shows a message with the number of rows affected. if the number of rows in the message looks OK, then you can now replace ROLLBACK with COMMIT and run it again to make it permanent: BEGIN TRANSACTION; DELETE FROM Employee WHERE DepartmentID = 13; COMMIT; -- save changes or if like me, you want to actually see the actual resulting data first instead of just the number of rows affected, then you can add a SELECT after the DELETE statement in the transaction and do the same: BEGIN TRANSACTION; DELETE FROM Employee WHERE DepartmentID = 13; SELECT * FROM Employee; -- to see what the data would look like after the DELETE ROLLBACK; -- cancel changes

Another simple trick is to use timestamps instead of flags.

Bruh, I think your manager was defective.

Thinking back on this. If management had noticed, then they would've sent me home, and called in other developers to fix the database. I suspect that would've turned into an all nighter, as everyone would contribute their own ideas and processes to fix it. And all the while being micro-managed. I certainly would've been fired.

😅😅😅

I’ve done this a number of times with whole database backups or sometimes just table backups. It has been a lifesaver more than once.

I don't get why on one line

So that this doesn't happen as in the video. Or if one selects the update/delete code and runs it (as it is frequently done in SQL Server Management Studio), one could forget to select the line with WHERE filter. It depends on the editor, of course. But I always write non-complex update/delete in one line.

thats transactions

The transaction query pisses me off because my company trained me on transactional queries just to tell me I could "just use a select to see what is effected" prior to running queries

Well i think his mindset was 1 small error is never enough. Make it 5 small human errors and there goes the production db.

Nah, small human errors are to be expected. People aren't perfect. That's why you need redundancy if you really want the least amount of accidents. The airline industry is so safe because they expect both human errors and technical issues to occur and have systems and procedures in place to mitigate that. Instead of just saying "skill issue" when an airplane crashes, the national authority creates a detailed report with recommendations to prevent further incidents like it.

@@Kenionatus ya, i watch the crash investigation videos too and my god, i wonder how much they actually invest in safety.