It looks like SQLite was meant to be a modest application's dedicated SQL enabled data store.  It was never meant to be concurrent, multiuser or intensely transactional.  A database professional would say that's a stupidly lazy programmer trick.

On a similar note I've been reading software engineering books which say letting the data architects engineer the database is a bad idea,  just let the programmers evolve the disperate databases and stores as they use agile methodology to evolve the enterprise systems -- I think of the poor accountants and data scientists, and think "why am I listening to a software engineer tell me how to architect the data on the premise organizing the data is a lost cause anyway which only slows the enterprise's agile?"

On Thu, Dec 29, 2022, 20:20 George Toft via PLUG-discuss <plug-discuss@lists.phxlinux.org> wrote:
I made a mistake in an application by using SQLite3.  I read about
SQLite's advantages over MySQL in that it has no network stack, so it's
faster.  My testing showed that was kinda true - it was faster mostly,
until multiple tasks started accessing the database concurrently.  I
applied some fixes I found on the Internet and that helped, then I got
clever and wrote a wrapper to prevent contention over the database.  I
tested with 60 concurrent requests and it worked fine.  The code made
its way into production.  A couple weeks later, in a perfect storm of
slash-dotting, we got hit with triple the load we ever experienced.  One
of the storms was the cron job that updated a record in the database. 
The field update failed and all of the other processes relying on that
field failed.  This was the only outage my team suffered in 2021.  I
switched over to MySQL (MariaDB) and never looked back.  Haven't had a
self-induced outage in over a year.

And then one of our vendors uses SQLite to store client information
(client as in client-server) in the licensing server, and guess what -
we figured out how to break it without even trying.  I actually had the
opportunity to have some 1:1 time with the product manager, and I was
letting him know how his licensing scheme was a huge risk and a single
point of failure.  About that time, the CIO of a South African bank
comes up and chimes in about what a piece of crap the licensing system
was, major single point of failure.  Product manager just turned his
back and walked away.  Meanwhile, I took the lesson from the CIO and had
my team apply it to our infrastructure after our 3rd database crash.  No
license server, no functionality.  Fortunately, it was still in
development and didn't impact anyone.

I am not a fan of SQLite.  Sure, put it in an embedded device, but not
anything connected to a network.

Regards,

George Toft

On 12/28/2022 9:45 AM, Steve Litt via PLUG-discuss wrote:
> Keith Smith via PLUG-discuss said on Tue, 27 Dec 2022 19:02:42 -0700
>
>> SQLite surly looks cool, however I would not call is a replacement for
>> dBase III.  dBase III was very structured and provide the ability to
>> create forms with widgets.
> IIRC dBase could make only CLI forms, not GUI forms. If one is willing
> to restrict one's self to CLI on an 80x25 screen, it's trivial in any
> language to create functions say() and get(). This is even easier today
> because you can represent the screen as a 25x80 2 dimensional array,
> rather than having to construct it from the top down the way you did
> when 20K was unaffordable.
>
>> It looks like SQLite would require some programming and the use of
>> ncurses or Qt... or maybe some other screen building language.  Am I
>> wrong?
> It would be more professional to use nCurses, but you can use plain old
> screen writes if you wanted to. As far as Qt, my understanding is
> that dBase never could do proportional spacing or different fonts.
>
>> Still it is pretty cool!!
>> Microsoft owns Visual FoxPro ... why not trim that down?
> No need to rely on Microsoft. Harbour Project is a Free Software
> Clipper almost-workalike. https://harbour.github.io/
>
>> MS also owns MS-Access which is a kludge in my opinion.
> Access was a nice DB design tool, but I wouldn't trust it to hold my
> data.
>
> SteveT
>
> Steve Litt
> Autumn 2022 featured book: Thriving in Tough Times
> http://www.troubleshooters.com/bookstore/thrive.htm
> ---------------------------------------------------
> PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> https://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list: PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss