TurboStitchGIF: A fast, header-only C GIF decoder without dynamic allocations, ideal for embedded systems and cross-platform projects. - Ferki-git-creator/TurboStitchGIF-HeaderOnly-Fast-ZeroAllocat...

Postmodern immutable and persistent data structures for C++ — value semantics at scale - arximboldi/immer

This series has used two sources for the same information. msdb records what the instance did. RESTORE HEADERONLY reads what's in the files. They describe the same backups and disagree on almost every name. Code that reads from both, which is most code that does anything useful here, ends up translating between them, and the translation is where mistakes get made.

Point RESTORE HEADERONLY at a full backup and you get one row. Point it at the file a fifteen-minute log backup job has been appending to since Sunday and you get several hundred. Each row is a separate backup set inside one physical file. Restoring from that file means naming which set you want, and the column that identifies it is…

A scheduled job that had run for months started failing after a server was upgraded. The message in the job history: Msg 3013, Level 16, State 1, Line 1 RESTORE HEADERONLY is terminating abnormally. Read that as a DBA and you go looking at the backup file: corruption, truncation, a share that went away, a service account that lost permission.

In part 1 I used msdb to find a database whose newest full backup had aged past a week. msdb tells you a backup happened. It doesn't tell you the file is still readable, or which database it really came from. For that you have to open the file, and RESTORE HEADERONLY is how. It reads the header of every backup set on a device and returns one row each, without restoring anything.