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