3 ms·

I volunteered at an archaeology lab run by the state govt a few months ago. Knowing I was a data engineer, one of the archaeologists asked me to take a look at

by wswope 11mo ago

I volunteered at an archaeology lab run by the state govt a few months ago. Knowing I was a data engineer, one of the archaeologists asked me to take a look at the cataloging system he’d cobbled together on his own: a shared-drive Access database with a full-featured CRUD interface that the whole office had been using for years. I was able to clean up one stray bug he had, and confirm his suspicion that one particular action was running slow because it had to touch multiple files by necessity (he’d rolled his own sharding) — but generally speaking, it was a work of art more effective than anything I could’ve ever come up with. Sometimes the “dirty hacks” are the best solutions.

skydhash 11mo ago
The avoidance of dirty hacks are not because they don’t work. They do and can be pretty X-effective when you’re short on X. But the end result is that when you need to switch away from the hacks, then the interest paid on X can be enormous. If X includes time, it may never be repaid.
- WorldMaker 11mo ago
  Directly related to which is the tech debt that accumulates just by using Access files in a shared folder. Access wasn't intended to work that way. It is documented in many places in Access' manuals to never do that. But it works and most versions of Access don't warn you when they detect you are using a shared folder, so most Access users don't question it. But I have seen the maintenance burden first hand of solving weird Access lock file problems (if I never have to manually find and delete an .LDB file again, that would be great) and silent corruption issues and more. I've seen the workarounds of auto-backups of the shared folder and then auto-restores of those backups when silly things happen like the .MDB file is not the expected file size. There's a special "joy" in needing to know the many under-the-hood versions of Access files and seeing apps that consume and/or produce more than one version at a time. That's just to maintain existing "apps", trying to migrate that data to modern databases for new apps is its own "joy" as well.
supportengineer 11mo ago
The best thing you can do in a situation like this is spend an enormous amount of time just documenting everything. Document all of the behaviors. You will need that before you even start on any kind of a re-implementation

by wswope 11mo ago

skydhash 11mo ago

The avoidance of dirty hacks are not because they don’t work. They do and can be pretty X-effective when you’re short on X. But the end result is that when you need to switch away from the hacks, then the interest paid on X can be enormous. If X includes time, it may never be repaid.

WorldMaker 11mo ago
Directly related to which is the tech debt that accumulates just by using Access files in a shared folder. Access wasn't intended to work that way. It is documented in many places in Access' manuals to never do that. But it works and most versions of Access don't warn you when they detect you are using a shared folder, so most Access users don't question it. But I have seen the maintenance burden first hand of solving weird Access lock file problems (if I never have to manually find and delete an .LDB file again, that would be great) and silent corruption issues and more. I've seen the workarounds of auto-backups of the shared folder and then auto-restores of those backups when silly things happen like the .MDB file is not the expected file size. There's a special "joy" in needing to know the many under-the-hood versions of Access files and seeing apps that consume and/or produce more than one version at a time. That's just to maintain existing "apps", trying to migrate that data to modern databases for new apps is its own "joy" as well.

supportengineer 11mo ago

The best thing you can do in a situation like this is spend an enormous amount of time just documenting everything. Document all of the behaviors. You will need that before you even start on any kind of a re-implementation