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: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list: [email protected]
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss
