References, Outlook, Software brokenness, Fingerprint, Transact-SQL-Backup

Once again classic problem, receiving data without exact reference information what's it related to. I've seen this with so many projects, it's kind of annoying. You know, this feedback is related to the green car last week or something. Ok, what's the exact transaction reference code? Eeh, last week, green car. No, that's not good enough, sorry. This is totally normal, when absolute noobs do it. But it's extremely annoying when professionals do the same fail. Either, there's unique absolute reference, or there isn't and if there isn't, then forget it. Any heuristics will be extremely unreliable and just screw things up and cause bad data quality. In this case, there are plenty of uniqueish identifiers, but none of those is absolutely guaranteed to work, nor being unique with required probability. Sigh. - This just reminded me that I just last week dealt with similar case, with totally different project and data set. Unfortunately this is so common.
Once again more problems with Outlook email, I just hate it how unreliable it is. My own server used to be much more reliable.
Bit later more problems with Microsoft Outlook Email deliverability, it seems that they're really eager to block larger groups of addresses and or AS numbers, without considering that there are several separate operators using that address space.
And more issues with Microsoft Blacklisting SMTP delivery based on ASN alone. Sigh, unfortunately this is nothing new. This is happening way too often, and it's like fighting against windmills. My tip? Don't use email providers which are to eager to block emails, because then it's your, yes, your own fault, if you're missing something. Don't try to push the blame to others.
Software Engineers and Developers. Hue hue. First they create code which crashes if something goes wrong. When someone complains about this, next they fix it by adding infinite loop without any delay which only exits if the operation is successful. Yeah, you already guessed what that will cause. - Sigh... Business as usual, nothing new. I've written so many times how things like these are handled correctly, but nope. Standard engineer doesn't understand stuff like that.
In some cases broken software is pretty deadly. File systems, memory management, data compression, backups, hashing, etc. Also broken hardware can be just as painful. It can lead to absolutely horrible mess to deal with and agonizing mental pain and rage.
Public key fingerprints - should be checked or not and if any fingerprint should be accepted. Sigh. Sure, it's easier if we just accept any fingerprint or public key without any checking, much less trouble. - Oh yeah, and just yesterday we had endless similar discussion about SSL certificates. Nothing new. Answer is of course yes and no depending on situation and requirements. Also strict requirements for verifiable certificates is just one reason why encryption won't be used. Because it's still a major burden.
Transact SQL BACKUP - When through all BACKUP related parameters, tested and played with those to figure out what the meaning exactly is in specific situations. All that TAPE stuff. ;) Be kind, rewind. What's the difference between creating a backup, and or creating copy_only, if log should be truncated or not and what's the difference between backing up database versus file backups vs file groups - and so on. What should be done with recovery log, etc. How long backup data sets are retained. Database Files and Filegroups. In my case(s), it seems that there's no particular reason to use file (group) backups. kw: partial bckup, differential backup, Microsoft SQL Server, mdf, ndf, ldf. Also read about Instant File Initialization. Just one of the standard trade-offs which I've written so much about.