101–110 of 112 posts
One can form a set by specifying just a table, or tune more by JOINs and further with WHERE clause.
Well, of course a JOIN is just one way to say WHERE. Still, when properly joined, the resulting set may not need a WHERE in UPDATE.
A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
I try to start any UPDATE or DELETE by writing out a transaction first: BEGIN TRAN; -- TODO: update statement ROLLBACK; Usually I'll run it with the ROLLBACK first, to confirm that it impacts the number of rows I'd expect, and only then change my ROLLBACK to a COMMIT.
Run code first, throw an error to force rollback the transaction...
A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
Linq is closest to the a more natural querying language we have come up with. Too bad it doesn't do update.
Earlier quoted context omitted.
Point being that "ls /path; rm $!" deletes something entirely different than "/path". What you want is "ls /path; rm $_". Even then, the above is fairly pointless. At the time you look at what you are deleting, it's gone.
I think you misunderstood the previous comment. I think that firstly "ls /path" is entered and if the result is ok, then "; rm $_" is added to the copy of the command then executed.
1. ls /path
2. rm
(where "escape" "dot" brings up last argument) without the need to fiddle around with dollar signs underscores, exclamation marks, etc. to prevent further mistakes (e.g. "was it $! or !$ ?", shell expansion, etc)
A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
Sql is not the best language. As someone put it once "The entire database industry is hauling a massive SQL-shaped parachute behind them. This complexity creates a drag on everything downstream." Linq is closest to the a more natural querying language we have come up with. Too bad it doesn't do update.
Earlier quoted context omitted.
This is an example of what I mean by "AI Hard". Yes, obviously, rolling updates is an improvement over non-rolling updates at scale. However, you still have things like "this update severs the machine from the management system due to unexpected XYZ", "this update is fine until it's rolled out to 80% of the world, at which point interactions with the other deployed systems hammer the system so hard the management int…
I think the only answer is the branch the universe, apply your changes, and if things go wrong, send a quantum tunneled bit signal to the control universe that those changes were bad. Then destroy the universe, nobody will ever know.
Somethings probably randomly fail, but because entropy and time is randomly selected we find ourselves in the successful ones.
Earlier quoted context omitted.
I consider any SQL client that doesn't have implicit transactions as broken. Just too easy to make mistakes. However even with that, I agree with your second point. I always type -- commit in my SQL client and then highlight "commit" and execute only the highlighted text. That way I don't commit anything if I accidentally trigger the "execute all" action.
Yes, but mind you I once locked up the database for my colleagues by not realising the consequences of implicit transactions in a DB client. It was a long time ago, but I think it was with SQLPlus on Oracle - and presumably staging or something non-prod since it's not a particularly vivid memory!
I went in there to adjust some data so that one of our dev users could re-publish some data which would then be synchronized to another database(update foo set published = false) and I couldn't understand that it wouldn't update in the UI.
I ended up telling him I'd have to get back to him, and the issue didn't dawn on me until the app logs started spitting out errors about not being able to retrieve a connection from the pool. YIL about pending transactions in DBeaver.
When dealing with azure app services on the command line, you specify the slot with the `-s ` flag.. but if you don't, it defaults to the production slot.
I'm really not sure what kind of moron though that was a good default, because the az CLI doesn't ask you for confirmation for anything. If you run `az webapp restart` you just restarted the production system.
Earlier quoted context omitted.
I once saw a coworker get destroyed by a rendering glitch in SSMS - he had GPU acceleration enabled and didn't notice his text selection highlight glitching out, smashed F5 on a query that looked like it had a where clause selected but if you fiddled with the scrollbar suddenly it wasn't actually selected. I noticed his query blocking everything and killed it, walked over to his office like WTF and he reran it right…
The GPU accelerated text rendering in SSMS 18 is incredibly bad. The other thing it likes to do sometimes is continue showing the text from tab A when you switch to tab B, until you scroll (not possible in short snippets) or edit it (and only the edited part updates!)
A particularly nasty aspect of SQL UPDATE syntax is the predicate order, i.e. SET is before WHERE. So when you type it in order, there's a dangerous phase you have to go through if you hit enter by accident. Having run an `mkfs.ext3 /dev/sda` (note the missing partition number) by accident, I've learned to start potentially destructive commands by typing first whatever makes that command a comment (# in shell, -- in…
I try to start any UPDATE or DELETE by writing out a transaction first: BEGIN TRAN; -- TODO: update statement ROLLBACK; Usually I'll run it with the ROLLBACK first, to confirm that it impacts the number of rows I'd expect, and only then change my ROLLBACK to a COMMIT.