@ErikReasonableRatesDarling Regarding lock compatibility battleship, the conflicts don't seem so bad to me. In essence, S conflicts with X. Most of the entries show N for No Conflict.
as it was just recently the case on this question of mine - I want to show the result of a query, but I cannot show server names and other specific properties that would potentially cause harm.
however, I enjoy details and clarity, my question is:
visually the way I did - blurring all with red on...
When looking at the deadlock graph:
Update query - SPID 75
The update query locking (spid 75) is pretty straightforward, an X (exclusive) lock is requested on the key/row value, while that row is currently locked by the select query.
The update query also holds an IX (Intent exclusive) lock...
Interesting example using a single table (but multiple accesses) in a single statement
This is only tangentially related, but to authenticate with github, I have a 2FA key, which has lately got me wondering what happens if my heirs want to login to something after I'm gone, but need to find (and use) this key. I think they will be very unlikely to understand authentication sufficiently to make it work.
@HannahVernon my understanding is that account recovery keys bypass mfa. i've printed mine out and left them in a safe deposit box. you can also nominate a successor
Chrissy LeMaire did a pretty comprehensive writeup along with a few other folks on this a few years ago github.com/potatoqualitee/eol-dr
FWIW at present i've just left a list of "who to ask for help" in specific sections of my hit-by-a-bus doc for things i think are likely to be difficult to grok for the target audience
but also back to your original point - in addition to having a couple named people who know how to use mfa & would be available & happy to help your successors listed in the DR doc, i also have one-time-use recovery keys printed & secured together for all the "major" mfa secured credentials