IIRC, MS Access allowed that, which explained a lot of its popularity.
IIRC, MS Access allowed that, which explained a lot of its popularity.
Apart from quality (!), SQLite's main advantage over these products is broad platform support. And continued existence.
Access is really meant for single-user scenarios I feel. Maybe the locking mechanism has gotten better but for multiuser access I tell people to use a real SQL database.
[https://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine]
In a lot of cases, I've found it to be the best tool for a temporary or one-off (preferably smaller scale) data mining/massaging project. The query-building interface was the way I originally learned the basics of relational databases, and it also helped me get a better grasp of SQL-- the ability to flip back & forth from the GUI query builder to the SQL it generates is nice.
On the multiuser side, however, I have found a couple workarounds in the past. If you have everyone operate locally and space out their central database connections to intermittent, automated burst queries, you can get more concurrent users than you might expect. It helps to have fewer users per table, as well, and of course it really helps if they don't need to see the most recent adds/changes in real time.
It was quite frankly the most productive custom business software package I have ever used. Literally would take 10 people a week to do something custom you could do in an afternoon with 1 person in Access. I suspect the same is true now.
SQL Server was a crap load easier to back up reliably
I loved the Clipper 5 OOP capabilities, sadly Visual Objects tried to be too much like Visual Basic and some of the easiness was lost.
There was still a lot of weird behavior, though, and while you could reduce data loss you couldn't eliminate it.
I'm probably going to have nightmares filled with screens of the access database corruption dialogs
Berkeley DB also supports multiple processes accessing a database concurrently, as far as I know.
I was wondering if the authors were referring to SQL-like databases, but MS Access seems to be one?
> Most SQL database engines are client/server based.
I skipped it for brevity.
The reason access was popular was it made any middle manager that could wield an Excel spreadsheet think they could build a database.
And plenty of other file-based DBs such as Borland’s Paradox and the db engine, dBase; pretty sure FileMaker, too.
A server is something that listens for commands from various clients and executes them.
If we reduce things to the absurd we stop being able to reason about things.
Sorta but not really. The fact people have worked backwards from marketing names to try and constructively define inherently self-contradictory branding (rather than create a descriptive category into which we place questionable names and ignore them) is an embarrassment for everyone except the marketing departments.
Ill give u that its hard to discern when a thing is a real change and when it isnt, as the titans of industry try to peacock around.
Id just examine what they actually mean, for good measure. Theyre trying to sell things they have no idea about - but thats why the hierarchy of commerce is.
I agree with you that it take a bit to marry both, but the stretch isnt far.
Im also avoiding criticising the Author for not sticking to the main def, since id then be red-herringing the post.
That is like the least relevant thing on that entire page, to be frank. "SQLite is Serverless" is specifically referring to SQLite being an embeddable library that runs in the same process (and same thread, even) as your application vs. the client-server architecture (database in another process, with communication via a port) that DBMSes like MySQL and co have.
> Im also avoiding criticising the Author for not sticking to the main def
The "main definition" (i.e. the web dev buzzword) came into being years after this post was written.