You lost the ability to enjoy it forever, and that’s what the language at time of sale said you’d have.

Had no trouble here on mobile.

Couldn’t agree more. It’s a great shell and scripting language. It’s object-oriented nature, native support for virtually every text format (csv, json, xml) and great libraries for others (yaml, excel), awesome regex and web/rest services support… it’s hard to beat and works on virtually every platform.

Too few people in the Linux community will even look at it though since it has MS name on it.

Can prevent a restore, whereas doing the update with auto commit guarantees a restore on (mostly) every error you make

Exactly. Restores often result in system downtime and may take hours and involve lots of people. The backup might not have the latest data either, and restoring to a single table you screwed up may not be feasible or come with risk of inconsistent data being loaded. Even if you just created the backup before your statement, what about the transaction coming in while you’re working and after you realize your error? Can you restore without impacting those?

You want to avoid all of that if possible. If you’re mucking with data that you’ll have to restore if you mess up, production or not, you should be working with an open transaction. As you said… if you see an unexpected number of rows updated, easy to rollback. And you can run queries after you’ve modified the data to confirm your table contains data as you expect now. Something surprising… rollback and re-think what you’re doing. Better to never touch a backup and not shoot yourself in the foot and your data in the face all due to a stupid, easily preventable mistake.

And always use a transaction so you’re required to commit to make it permanent. See an unexpected result? Rollback.

Not to ask a possibly silly question but I haven’t seen these questions asked and I don’t know your network experience. You’ve supplied the actual network address of your pihole machine and not the 192.168.1.250 address shown, right? And you’ve set your pihole server up to have a static ip address as well, correct? You don’t want it assigned dynamically and therefore randomly everytime it renews its lease.

If the ip address is statically assigned - either hard-coded as static on the machine or at least being statically assigned on your router via its mac address - then setting the dns server on your router should work. I would however assign 2nd and 3rd dns servers as Google dns or cloud flare ip addresses in case your pihole server is ever down. (1.1.1.1, 8.8.8.8 or some of the others). If that’s all confirmed and your machines are not receiving your configured dns settings from the router, it’s possible (seems unlikely) the spectrum supplied router is ignoring the settings and assigning their dns servers. If so, buy your own router and put it between your home network and the spectrum hardware. Then you have control and it doesn’t matter what their hardware does. You’ll just set yours up on a different subnet - 192.168.x where x doesn’t match the same value as the spectrum network - and you should be good to go.

Good luck!