4 ms·

Access is actually designed to work in a multiuser situation over a LAN for concurrent read and write. SQLite isn't afaik. As long as the LAN was cabled I never

by tenant 7y ago

Access is actually designed to work in a multiuser situation over a LAN for concurrent read and write. SQLite isn't afaik. As long as the LAN was cabled I never saw any issues. The only reason it was necessary to move to a server type database was because people were insisting on wifi networking.

klez 7y ago
I'm not sure I understand what the physical transport has to do with this. Can you please expand a bit?
- wolf550e 7y ago
  Maybe disconnect and reconnect cause windows network share to lose locks or something like that.
  - tenant 7y ago
    Yes, for Access (and sqlite?) it is the client computers that do the edits directly to the database file, rather than via a mediating server side process, so they are particularly vulnerable to network interruptions while in the middle of an edit. Cable is far more reliable than wifi and so far fewer interruptions. I think that's it.
    - makapuf 7y ago
      Ok but you cant really say you support network access if you rely on it to be flawless. Working fast, maybe but not reliably working if your network is not super reliable is not really support.
      - tenant 7y ago
        It was a different time.
        aksss 7y ago
        Back in the day, which was a Wednesday
- im3w1l 7y ago
  Race conditions not triggering when the transport is fast enough?
paulie_a 7y ago
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.

by tenant 7y ago

klez 7y ago

I'm not sure I understand what the physical transport has to do with this. Can you please expand a bit?

wolf550e 7y ago
Maybe disconnect and reconnect cause windows network share to lose locks or something like that.
- tenant 7y ago
  Yes, for Access (and sqlite?) it is the client computers that do the edits directly to the database file, rather than via a mediating server side process, so they are particularly vulnerable to network interruptions while in the middle of an edit. Cable is far more reliable than wifi and so far fewer interruptions. I think that's it.
  - makapuf 7y ago
    Ok but you cant really say you support network access if you rely on it to be flawless. Working fast, maybe but not reliably working if your network is not super reliable is not really support.
    - tenant 7y ago
      It was a different time.
      - aksss 7y ago
        Back in the day, which was a Wednesday
im3w1l 7y ago
Race conditions not triggering when the transport is fast enough?

paulie_a 7y ago

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.