4 ms·

It might have been designed for it. It was poorly designed for it. It was a clustfuck of corruption when actually utilized

slfnflctd 7y ago
You basically had to engineer around the corruption risks for anything actually in production. Data redundancy, old-school 'Save' buttons (your work isn't properly saved until you click it, because it sends copies of that work to multiple backends) and isolating users as much as possible to their own 'shards' was part of how I saw it kludged through in the real world. There was still a lot of weird behavior, though, and while you could reduce data loss you couldn't eliminate it.
- paulie_a 7y ago
  Penny wise pound foolish. I had a president waste two to three hours a day instead of using a 40 dollar service to take care of the incredibly simple and repetitive task. Eventually when I was planning to leave anyways I asked him what his time was with per hour. I guess it was less than minimum wage at the time. (5.25 an hour) I'm probably going to have nightmares filled with screens of the access database corruption dialogs
  - tenant 7y ago
    What's anyone's time worth? Might have kept him from doing something foolish.
    - paulie_a 7y ago
      Valid point. He did defraud the federal government for 600k. If he had more time on his calendar he could have fucked over the American taxpayers ever more.
tenant 7y ago
It depended. It suited a small cabled office with 10 to 15 computers fine. I saw such setups work fine for 12 years without corruption. But when wifi came along people started connecting that way, sometimes unintentionally, and corruption became an issue. So then we bit the bullet and moved the backend to a server database. Not a single database corruption since.
- afiori 7y ago
  But this is the difference between supporting concurrent access or not. The fact that the feature relied so much on network reliability means that race conditions still existed.
  - tenant 7y ago
    I'm not arguing with you but the fact remains that unlike SQLite, Access doesn't lock the database file so that only one user can write at a particular moment, it's more granular than that. It's also the fact that this worked very well for databases on small cabled LANs where no more than a dozen-ish computers might be interacting with the database at any one time. It was never designed for use over the internet (having said which I have maintained a forum running an Access mdb file as its backend since forever without a hitch the forum software process does the database edits so it's like a database server process in a way I suppose).

slfnflctd 7y ago

You basically had to engineer around the corruption risks for anything actually in production. Data redundancy, old-school 'Save' buttons (your work isn't properly saved until you click it, because it sends copies of that work to multiple backends) and isolating users as much as possible to their own 'shards' was part of how I saw it kludged through in the real world. There was still a lot of weird behavior, though, and while you could reduce data loss you couldn't eliminate it.

paulie_a 7y ago
Penny wise pound foolish. I had a president waste two to three hours a day instead of using a 40 dollar service to take care of the incredibly simple and repetitive task. Eventually when I was planning to leave anyways I asked him what his time was with per hour. I guess it was less than minimum wage at the time. (5.25 an hour) I'm probably going to have nightmares filled with screens of the access database corruption dialogs
- tenant 7y ago
  What's anyone's time worth? Might have kept him from doing something foolish.
  - paulie_a 7y ago
    Valid point. He did defraud the federal government for 600k. If he had more time on his calendar he could have fucked over the American taxpayers ever more.

tenant 7y ago

It depended. It suited a small cabled office with 10 to 15 computers fine. I saw such setups work fine for 12 years without corruption. But when wifi came along people started connecting that way, sometimes unintentionally, and corruption became an issue. So then we bit the bullet and moved the backend to a server database. Not a single database corruption since.

afiori 7y ago
But this is the difference between supporting concurrent access or not. The fact that the feature relied so much on network reliability means that race conditions still existed.
- tenant 7y ago
  I'm not arguing with you but the fact remains that unlike SQLite, Access doesn't lock the database file so that only one user can write at a particular moment, it's more granular than that. It's also the fact that this worked very well for databases on small cabled LANs where no more than a dozen-ish computers might be interacting with the database at any one time. It was never designed for use over the internet (having said which I have maintained a forum running an Access mdb file as its backend since forever without a hitch the forum software process does the database edits so it's like a database server process in a way I suppose).