I am not sure about MS Access. From what little I know 2 people opening from network drive would mostly result in database being corrupt.
MS Access "allowed" it. SQLite actually works.
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.
The main problem that I see for using sqlite is exactly for it being 'Classic Serverless'. Because how does one keep an up te date backup? Deploying to Heroku, Dokku, AWS Lambda and such means the sqlite file will be lost on a crash or new deploy. Even a VM can crash. Export to S3 on every write? Maybe if changes do not happen often, so only for specific use cases (and actually I think you should just generate static…
>how do you back up a file
It's a valid concern in so far as that any standalone database setup you would use at a serverless provider has backups already taken care of (for example AWS Lambda with AWS RDS has backups built into RDS). If I deploy SQLite instead I have to take care of backups myself, and that might not be trivial to get right.
The main problem that I see for using sqlite is exactly for it being 'Classic Serverless'. Because how does one keep an up te date backup? Deploying to Heroku, Dokku, AWS Lambda and such means the sqlite file will be lost on a crash or new deploy. Even a VM can crash. Export to S3 on every write? Maybe if changes do not happen often, so only for specific use cases (and actually I think you should just generate static…
It's just a single file. Easier to backup than any other database. Also I don't think any cloud provider/database provides an always up to date backup other than a standby replica (which isn't also a backup exactly).
If I remember the "ways to corrupt SQLite databases" page discussed a few days ago, backing up SQLite isn't entirely trivial. By default there are up to three files that have to be copied simultaneously, else you risk corruption. The optimum is to run the backup command to create a copy, but that requires realizing this exists.
It's just a single file. Easier to backup than any other database. Also I don't think any cloud provider/database provides an always up to date backup other than a standby replica (which isn't also a backup exactly).
If I remember the "ways to corrupt SQLite databases" page discussed a few days ago, backing up SQLite isn't entirely trivial. By default there are up to three files that have to be copied simultaneously, else you risk corruption. The optimum is to run the backup command to create a copy, but that requires realizing this exists.
If you do find the link could you please share it here. I think I've been hit by it once before.
Also, it's comparatively simpler than other DBMS's like Postgres or MySQL.
> Of those that are serverless, SQLite is the only one known to this author that allows multiple applications to access the same database at the same time. IIRC, MS Access allowed that, which explained a lot of its popularity.
Waaaaait wouldn’t that mean the file system is the server, with some binary API and responsible for handling concurrent access and locks for the entire file? LOL.
That just circle jerk. There is an agreed upon def of serverless.
If we reduce things to the absurd we stop being able to reason about things.
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.
I'm not sure I understand what the physical transport has to do with this. Can you please expand a bit?
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.
I'm not sure I understand what the physical transport has to do with this. Can you please expand a bit?
Maybe disconnect and reconnect cause windows network share to lose locks or something like that.
If I remember the "ways to corrupt SQLite databases" page discussed a few days ago, backing up SQLite isn't entirely trivial. By default there are up to three files that have to be copied simultaneously, else you risk corruption. The optimum is to run the backup command to create a copy, but that requires realizing this exists.
If you do find the link could you please share it here. I think I've been hit by it once before. Also, it's comparatively simpler than other DBMS's like Postgres or MySQL.
The main problem that I see for using sqlite is exactly for it being 'Classic Serverless'. Because how does one keep an up te date backup? Deploying to Heroku, Dokku, AWS Lambda and such means the sqlite file will be lost on a crash or new deploy. Even a VM can crash. Export to S3 on every write? Maybe if changes do not happen often, so only for specific use cases (and actually I think you should just generate static…
Alternatively, given that it's ACID, you could just take a snapshot of the file system/volume in question, and do a recovery on restore.
Edit: SQLite also has WAL files, so presumably one could just use tar/rsync to create the backup, and only the last file would be 'corrupted', so you'd lose the last (few) transaction(s):