3 ms·

Memories of waiting for months to get access to a MS SQL database and ending up putting an Access database on a network share for multiple user access instead.

by afavour 11mo ago

Memories of waiting for months to get access to a MS SQL database and ending up putting an Access database on a network share for multiple user access instead. A horrible, horrible hack solution. But it worked!

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
codelikeawolf 11mo ago
> A horrible, horrible hack solution. But it worked! I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works! Edit: grammar
m3047 11mo ago
Not intended as an endorsement, but Access / FileMaker / 4D were all great solutions for low-contention, low-user count low / no code CRUD apps.

by afavour 11mo ago

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

codelikeawolf 11mo ago

> A horrible, horrible hack solution. But it worked! I ended up building an Access app at an enterprise-y company I used to work at because it would have taken years for IT to build it. The app did something super specific and kept needing super specific additional features, and there wasn't anything on the market that met our needs. The Access UI talked to another Access database on a shared network drive. I just found out that it's still being used heavily by several people every day, 17 years later. You pretty much nailed it, Access is hacky, but it works! Edit: grammar

m3047 11mo ago

Not intended as an endorsement, but Access / FileMaker / 4D were all great solutions for low-contention, low-user count low / no code CRUD apps.