It usually means a function returned nothing where you expected an object. Work backwards to whatever produced that variable rather than staring at the line that blew up.
It is one of those things everybody learns by accident and nobody teaches.
Learn what the common ones mean before you meet them at 1am. TypeError is usually the wrong kind of thing, AttributeError is usually None where you expected an object, KeyError means the key is not there, IndexError means the list is shorter than you think. Those four cover most beginner evenings.
That is why I like it as a teaching trick. It turns an abstract idea about references into one number you can watch.
Quick way to see it for yourself: print id(record) inside the loop. The same number every pass means one object. Different numbers mean you are making new ones.
Add print(i, values[i]) as the first line of the loop body and run it. Two seconds of output tells you more than twenty minutes of staring. One line means the exit is in the body; the same line forever means the counter is not moving.
Print debugging is unfashionable and it answers this class of question in about four seconds.
It also means you can keep the last few runs and diff them when something looks wrong, which is worth the storage on its own.
You have more than one Python and pip is installing into a different one from the interpreter running your script. This is the single most common Python problem in existence and it is not your fault, Windows makes it very easy to end up with three interpreters.
Diagnose it in two steps. In a REPL run import sys then print(sys.executable) - that is the interpreter running your code. Then run pip -V, which prints at the end which Python that pip belongs to. If those two paths differ, that is your entire bug.
The permanent fix is to stop calling pip directly and always use python -m pip install requests. That guarantees the install lands in the interpreter you just invoked. Same idea for environments: python -m venv .venv, activate it, then python -m pip install ....
Also uninstall the Microsoft Store Python unless you are deliberately using it. It sandboxes paths in ways that confuse everything else on the machine.
There it is. Pick one, remove the other, and use python -m pip from now on.
Six hours for 90 days suggests the backfill is not parallel across partitions. If each day is independent they should run concurrently, and at your volume that number should be closer to twenty minutes.
Fair, and probably the better order of operations. Try the light thing first.
Conda for this specific project, because of the compiler line. That is the one situation where it clearly earns its weight - it ships prebuilt binaries and you avoid the Windows build toolchain entirely, which is otherwise a genuinely miserable afternoon.
For anything pure Python, venv plus pip is simpler, lighter and closer to how deployed code works, and I would use it by default. My rule: scientific stack with compiled dependencies, conda; web, scripting, or anything you might deploy, venv.
Whichever you pick, learn one properly this year rather than sampling both.
Twenty five minutes is not slow. It only feels slow because you watched it.