On 2023-02-27 11:17, The Natural Philosopher wrote:
> On 27/02/2023 10:13, Carlos E.R. wrote:
>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>> <tnp@invalid.invalid> wrote:
>>>>>> I am pretty sure generally NO.
>>>>>> Otherwise databases would have a hard time working
>>>>>
>>>>> Data base applications work by having one thread that does the
>>>>> physical i/o for each file that contains the database. Multiple
>>>>> applications can use the database, but they don't do the i/o to the
>>>>> disk.
>>>>
>>>> Not all database applications work that way.
>>>>
>>>> For example, in MsDOS an application could lock for write a section
>>>> of a file, write that, then remove the lock. Another application
>>>> could be reading the same file, even writing in another section.
>>>>
>>>> This functionality was an add on: you needed to run the optional
>>>> share.exe. But Windows had it natively.
>>>>
>>>> I believe Microsoft Access works like that.
>>>>
>>>>
>>>> I am not sure this behaviour can be done in Linux. Long ago it could
>>>> not.
>>>>
>>> File lockining always existed at the level of IIRC whole files.
>>> But obliviously it is far far easier to have a databse engine
>>> accepting all requests and using (at least) just one process, if not
>>> one thread, to do all I/O
>>
>> Easier, depends. MS Access is trivially easy to use (for simple
>> databases).
>>
> You call that a database? I dont. Any more than SqlLite is a
> database...both are single user/process  access only.

LOL

Well, there is money in it ;-)

--
Cheers, Carlos.

On 2/27/23 1:19 PM, Carlos E.R. wrote:
> On 2023-02-27 11:17, The Natural Philosopher wrote:
>> On 27/02/2023 10:13, Carlos E.R. wrote:
>>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>>> <tnp@invalid.invalid> wrote:
>>>>>>> I am pretty sure generally NO.
>>>>>>> Otherwise databases would have a hard time working
>>>>>>
>>>>>> Data base applications work by having one thread that does the
>>>>>> physical i/o for each file that contains the database. Multiple
>>>>>> applications can use the database, but they don't do the i/o to the
>>>>>> disk.
>>>>>
>>>>> Not all database applications work that way.
>>>>>
>>>>> For example, in MsDOS an application could lock for write a section
>>>>> of a file, write that, then remove the lock. Another application
>>>>> could be reading the same file, even writing in another section.
>>>>>
>>>>> This functionality was an add on: you needed to run the optional
>>>>> share.exe. But Windows had it natively.
>>>>>
>>>>> I believe Microsoft Access works like that.
>>>>>
>>>>>
>>>>> I am not sure this behaviour can be done in Linux. Long ago it
>>>>> could not.
>>>>>
>>>> File lockining always existed at the level of IIRC whole files.
>>>> But obliviously it is far far easier to have a databse engine
>>>> accepting all requests and using (at least) just one process, if not
>>>> one thread, to do all I/O
>>>
>>> Easier, depends. MS Access is trivially easy to use (for simple
>>> databases).
>>>
>> You call that a database? I dont. Any more than SqlLite is a
>> database...both are single user/process  access only.
>
> LOL
>
> Well, there is money in it ;-)

Access has its place and uses - and the 3rd-gen drag-n-drop
form builder is something I wish they ALL had (ok, you CAN
have 'em - for $$$+). Where I'm at now the inventory DB is
on Access. Only one person uses it at a time anyhow and
several people have been able to figure out how to tweak
the forms/fields/etc a little, so ...

Now for the more-used stuff ... SQL Server or (preferably)
MySQL (not MariaDB). Thing is I'm pretty much the only one
who can mod those and it ain't THAT long until retirement
and there's no proper heir-apparent ......... (damn that
work-ethic ..........)

On 2023-02-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
> On 27/02/2023 10:13, Carlos E.R. wrote:
>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>> <tnp@invalid.invalid> wrote:
>>>>>> I am pretty sure generally NO.
>>>>>> Otherwise databases would have a hard time working
>>>>>
>>>>> Data base applications work by having one thread that does the
>>>>> physical i/o for each file that contains the database. Multiple
>>>>> applications can use the database, but they don't do the i/o to the
>>>>> disk.
>>>>
>>>> Not all database applications work that way.
>>>>
>>>> For example, in MsDOS an application could lock for write a section
>>>> of a file, write that, then remove the lock. Another application
>>>> could be reading the same file, even writing in another section.
>>>>
>>>> This functionality was an add on: you needed to run the optional
>>>> share.exe. But Windows had it natively.
>>>>
>>>> I believe Microsoft Access works like that.
>>>>
>>>>
>>>> I am not sure this behaviour can be done in Linux. Long ago it could
>>>> not.
>>>>
>>> File lockining always existed at the level of IIRC whole files.
>>> But obliviously it is far far easier to have a databse engine
>>> accepting all requests and using (at least) just one process, if not
>>> one thread, to do all I/O
>>
>> Easier, depends. MS Access is trivially easy to use (for simple databases).
>>
> You call that a database? I dont. Any more than SqlLite is a
> database...both are single user/process access only.

Many of the hits from this web search disagree:

https://duckduckgo.com/?q=sqlitemultiple+processes&hps=1&start=1&ia=web

This FAQ answer appears fairly authoritative:

https://www.sqlite.org/faq.html#q5

HTH

--
Robert Riches
spamtrap42@jacob21819.net
(Yes, that is one of my email addresses.)

On 2023-02-28 05:13, Robert Riches wrote:
> On 2023-02-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 27/02/2023 10:13, Carlos E.R. wrote:
>>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>>> <tnp@invalid.invalid> wrote:
>>>>>>> I am pretty sure generally NO.
>>>>>>> Otherwise databases would have a hard time working
>>>>>>
>>>>>> Data base applications work by having one thread that does the
>>>>>> physical i/o for each file that contains the database. Multiple
>>>>>> applications can use the database, but they don't do the i/o to the
>>>>>> disk.
>>>>>
>>>>> Not all database applications work that way.
>>>>>
>>>>> For example, in MsDOS an application could lock for write a section
>>>>> of a file, write that, then remove the lock. Another application
>>>>> could be reading the same file, even writing in another section.
>>>>>
>>>>> This functionality was an add on: you needed to run the optional
>>>>> share.exe. But Windows had it natively.
>>>>>
>>>>> I believe Microsoft Access works like that.
>>>>>
>>>>>
>>>>> I am not sure this behaviour can be done in Linux. Long ago it could
>>>>> not.
>>>>>
>>>> File lockining always existed at the level of IIRC whole files.
>>>> But obliviously it is far far easier to have a databse engine
>>>> accepting all requests and using (at least) just one process, if not
>>>> one thread, to do all I/O
>>>
>>> Easier, depends. MS Access is trivially easy to use (for simple databases).
>>>
>> You call that a database? I dont. Any more than SqlLite is a
>> database...both are single user/process access only.
>
> Many of the hits from this web search disagree:
>
> https://duckduckgo.com/?q=sqlitemultiple+processes&hps=1&start=1&ia=web
>
> This FAQ answer appears fairly authoritative:
>
> https://www.sqlite.org/faq.html#q5

Interesting.

--
Cheers, Carlos.

On 2023-02-28 03:46, 28A.I873 wrote:
> On 2/27/23 1:19 PM, Carlos E.R. wrote:
>> On 2023-02-27 11:17, The Natural Philosopher wrote:
>>> On 27/02/2023 10:13, Carlos E.R. wrote:
>>>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>>>> <tnp@invalid.invalid> wrote:
>>>>>>>> I am pretty sure generally NO.
>>>>>>>> Otherwise databases would have a hard time working
>>>>>>>
>>>>>>> Data base applications work by having one thread that does the
>>>>>>> physical i/o for each file that contains the database. Multiple
>>>>>>> applications can use the database, but they don't do the i/o to the
>>>>>>> disk.
>>>>>>
>>>>>> Not all database applications work that way.
>>>>>>
>>>>>> For example, in MsDOS an application could lock for write a
>>>>>> section of a file, write that, then remove the lock. Another
>>>>>> application could be reading the same file, even writing in
>>>>>> another section.
>>>>>>
>>>>>> This functionality was an add on: you needed to run the optional
>>>>>> share.exe. But Windows had it natively.
>>>>>>
>>>>>> I believe Microsoft Access works like that.
>>>>>>
>>>>>>
>>>>>> I am not sure this behaviour can be done in Linux. Long ago it
>>>>>> could not.
>>>>>>
>>>>> File lockining always existed at the level of IIRC whole files.
>>>>> But obliviously it is far far easier to have a databse engine
>>>>> accepting all requests and using (at least) just one process, if
>>>>> not one thread, to do all I/O
>>>>
>>>> Easier, depends. MS Access is trivially easy to use (for simple
>>>> databases).
>>>>
>>> You call that a database? I dont. Any more than SqlLite is a
>>> database...both are single user/process  access only.
>>
>> LOL
>>
>> Well, there is money in it ;-)
>
>   Access has its place and uses - and the 3rd-gen drag-n-drop
>   form builder is something I wish they ALL had (ok, you CAN
>   have 'em - for $$$+). Where I'm at now the inventory DB is
>   on Access. Only one person uses it at a time anyhow and
>   several people have been able to figure out how to tweak
>   the forms/fields/etc a little, so ...
>
>   Now for the more-used stuff ... SQL Server or (preferably)
>   MySQL (not MariaDB). Thing is I'm pretty much the only one
>   who can mod those and it ain't THAT long until retirement
>   and there's no proper heir-apparent ......... (damn that
>   work-ethic ..........)

We used MS Access at an ISP, back on 1998, for keeping track of second
level (client) incidents. The team could be 6 people using the database
at the same time (both read and write). There was one "database file" in
a desktop machine acting as server for the group, and then several
desktop machines running the application, which was another ms access
file. Sharing directories on the network. I don't remember anybody
reporting glitches related to concurrent access, besides two people
trying to write to the same record, but that was very rare because of
how we were organized.

Creating/maintaining the database and the applications/forms was
trivially easy. Libre Office is getting _now_ near to what ms access did
25 years ago. We could change our MS-A database in a day, even an hour,
not involving higher management. And we could obtain stats and graphs
which our management loved.

And MS Access was used because it was what the office people had access
to (all computers were provided with a full MS Office instance), and we
had people knowing it. The true enterprise database used Vantive.

So yes, MS Access is indeed a serious database used in the enterprise
office world.

--
Cheers, Carlos.

On 2/28/23 7:33 AM, Carlos E.R. wrote:
> On 2023-02-28 03:46, 28A.I873 wrote:
>> On 2/27/23 1:19 PM, Carlos E.R. wrote:
>>> On 2023-02-27 11:17, The Natural Philosopher wrote:
>>>> On 27/02/2023 10:13, Carlos E.R. wrote:
>>>>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>>>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>>>>> <tnp@invalid.invalid> wrote:
>>>>>>>>> I am pretty sure generally NO.
>>>>>>>>> Otherwise databases would have a hard time working
>>>>>>>>
>>>>>>>> Data base applications work by having one thread that does the
>>>>>>>> physical i/o for each file that contains the database. Multiple
>>>>>>>> applications can use the database, but they don't do the i/o to the
>>>>>>>> disk.
>>>>>>>
>>>>>>> Not all database applications work that way.
>>>>>>>
>>>>>>> For example, in MsDOS an application could lock for write a
>>>>>>> section of a file, write that, then remove the lock. Another
>>>>>>> application could be reading the same file, even writing in
>>>>>>> another section.
>>>>>>>
>>>>>>> This functionality was an add on: you needed to run the optional
>>>>>>> share.exe. But Windows had it natively.
>>>>>>>
>>>>>>> I believe Microsoft Access works like that.
>>>>>>>
>>>>>>>
>>>>>>> I am not sure this behaviour can be done in Linux. Long ago it
>>>>>>> could not.
>>>>>>>
>>>>>> File lockining always existed at the level of IIRC whole files.
>>>>>> But obliviously it is far far easier to have a databse engine
>>>>>> accepting all requests and using (at least) just one process, if
>>>>>> not one thread, to do all I/O
>>>>>
>>>>> Easier, depends. MS Access is trivially easy to use (for simple
>>>>> databases).
>>>>>
>>>> You call that a database? I dont. Any more than SqlLite is a
>>>> database...both are single user/process  access only.
>>>
>>> LOL
>>>
>>> Well, there is money in it ;-)
>>
>>    Access has its place and uses - and the 3rd-gen drag-n-drop
>>    form builder is something I wish they ALL had (ok, you CAN
>>    have 'em - for $$$+). Where I'm at now the inventory DB is
>>    on Access. Only one person uses it at a time anyhow and
>>    several people have been able to figure out how to tweak
>>    the forms/fields/etc a little, so ...
>>
>>    Now for the more-used stuff ... SQL Server or (preferably)
>>    MySQL (not MariaDB). Thing is I'm pretty much the only one
>>    who can mod those and it ain't THAT long until retirement
>>    and there's no proper heir-apparent ......... (damn that
>>    work-ethic ..........)
>
>
> We used MS Access at an ISP, back on 1998, for keeping track of second
> level (client) incidents. The team could be 6 people using the database
> at the same time (both read and write). There was one "database file" in
> a desktop machine acting as server for the group, and then several
> desktop machines running the application, which was another ms access
> file. Sharing directories on the network. I don't remember anybody
> reporting glitches related to concurrent access, besides two people
> trying to write to the same record, but that was very rare because of
> how we were organized.
>
> Creating/maintaining the database and the applications/forms was
> trivially easy. Libre Office is getting _now_ near to what ms access did
> 25 years ago. We could change our MS-A database in a day, even an hour,
> not involving higher management. And we could obtain stats and graphs
> which our management loved.
>
> And MS Access was used because it was what the office people had access
> to (all computers were provided with a full MS Office instance), and we
> had people knowing it. The true enterprise database used Vantive.
>
> So yes, MS Access is indeed a serious database used in the enterprise
> office world.

You don't need a nuclear weapon to swat a fly. The "big" DBs
like Oracle, SQL Server, MySQL - those are just way too much
work to handle a lot of trivial DB needs for a large segment.
Access works. It's ubiquitous. People can figure it out.

As for Libre ... they (or was it Star/Open-Office ?) used to
have an Access clone. Not quite as good, but it also worked
and people could cope. Then it went away. Libre's idea of
a 'database' now seems to be a front-end for their spreadsheet.

On 28/02/2023 15:49, 28A.I873 wrote:
> Access works. It's ubiquitous. People can figure it out.

I never could, but the moment I looked at Informix and MySQL it all made
perfect sense.

--
"I am inclined to tell the truth and dislike people who lie consistently.
This makes me unfit for the company of people of a Left persuasion, and
all women"

On Tue, 28 Feb 2023 10:49:15 -0500, 28A.I873 <28A.I873@noabzba.net> wrote:
> As for Libre ... they (or was it Star/Open-Office ?) used to
> have an Access clone. Not quite as good, but it also worked
> and people could cope. Then it went away. Libre's idea of
> a 'database' now seems to be a front-end for their spreadsheet.

Libreoffice has oocalc (aka "libreoffice --calc" for spreadsheets, and
oobase (aka "libreoffice --base") for databases.
https://books.libreoffice.org/en/BG72/BG72.html

Regards, Dave Hodgins

On 2/28/23 11:21 AM, The Natural Philosopher wrote:
> On 28/02/2023 15:49, 28A.I873 wrote:
>> Access works. It's ubiquitous. People can figure it out.
>
> I never could, but the moment I looked at Informix and MySQL it all made
> perfect sense.

Then you're not "regular people". Take that as
a complement ...

I've several NON-IT people who were able to create
and tweak an inventory DB using Access.. pix of
the hardware included. NONE could do it with
Oracle/MySql/SQL-SERVER ... no WAY. This means
that *I* don't have to worry about it, *I* don't
have to tweak it, *I* don't have to maintain it.
Does what it needs to do.

So no, I am NOT gonna diss Access. It DOES have
it's place and sphere and audience. And the
built-in 3rd-gen form builder ... wonderful.
IF you learn how to expand those form options
you can do kinda anything.

And stuff like FoxBase and FileMaker have their
place too.

Had to move a non-y2k MV database over to FileMaker,
SO much fun, long back. Frankly I prefer the
multivalue paradigm, but these days those DBs cost
too damned much.

On 2/28/23 12:01 PM, David W. Hodgins wrote:
> On Tue, 28 Feb 2023 10:49:15 -0500, 28A.I873 <28A.I873@noabzba.net> wrote:
>>    As for Libre ... they (or was it Star/Open-Office ?) used to
>>    have an Access clone. Not quite as good, but it also worked
>>    and people could cope. Then it went away. Libre's idea of
>>    a 'database' now seems to be a front-end for their spreadsheet.
>
> Libreoffice has oocalc (aka "libreoffice --calc" for spreadsheets, and
> oobase (aka "libreoffice --base") for databases.
> https://books.libreoffice.org/en/BG72/BG72.html
>
> Regards, Dave Hodgins

Don't like either. The <something>Office Access clone
was better. MIGHT have been legal issues with M$ ...

I'll have to check into it. So far as I know Open &
Star Office still exist.

Yea, a flat-file DB *is* kind of like a spreadsheet,
but you don't get the width/depth/breadth of the
faux-BASIC built into ACCESS and ALL those neat
hooks you can attach it too.

I love the multi-value DB paradigm, but these days
those are TOO EXPENSIVE. However a lot of my utilities
and apps build ascii-delimited MV records in the
old PICK style, SO easy to build. Never was able
to write a clean ALL-PURPOSE way to read/edit such
records alas ... "intent" kinda comes into the picture.
Mess with it awhile, you'll see what I mean .....

On 2/28/23 7:16 AM, Carlos E.R. wrote:
> On 2023-02-28 05:13, Robert Riches wrote:
>> On 2023-02-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
>>> On 27/02/2023 10:13, Carlos E.R. wrote:
>>>> On 2023-02-27 11:02, The Natural Philosopher wrote:
>>>>> On 27/02/2023 09:34, Carlos E.R. wrote:
>>>>>> On 2023-02-27 01:06, David W. Hodgins wrote:
>>>>>>> On Sun, 26 Feb 2023 18:32:38 -0500, The Natural Philosopher
>>>>>>> <tnp@invalid.invalid> wrote:
>>>>>>>> I am pretty sure generally NO.
>>>>>>>> Otherwise databases would have a hard time working
>>>>>>>
>>>>>>> Data base applications work by having one thread that does the
>>>>>>> physical i/o for each file that contains the database. Multiple
>>>>>>> applications can use the database, but they don't do the i/o to the
>>>>>>> disk.
>>>>>>
>>>>>> Not all database applications work that way.
>>>>>>
>>>>>> For example, in MsDOS an application could lock for write a section
>>>>>> of a file, write that, then remove the lock. Another application
>>>>>> could be reading the same file, even writing in another section.
>>>>>>
>>>>>> This functionality was an add on: you needed to run the optional
>>>>>> share.exe. But Windows had it natively.
>>>>>>
>>>>>> I believe Microsoft Access works like that.
>>>>>>
>>>>>>
>>>>>> I am not sure this behaviour can be done in Linux. Long ago it could
>>>>>> not.
>>>>>>
>>>>> File lockining always existed at the level of IIRC whole files.
>>>>> But obliviously it is far far easier to have a databse engine
>>>>> accepting all requests and using (at least) just one process, if not
>>>>> one thread, to do all I/O
>>>>
>>>> Easier, depends. MS Access is trivially easy to use (for simple
>>>> databases).
>>>>
>>> You call that a database? I dont. Any more than SqlLite is a
>>> database...both are single user/process  access only.
>>
>> Many of the hits from this web search disagree:
>>
>> https://duckduckgo.com/?q=sqlitemultiple+processes&hps=1&start=1&ia=web
>>
>> This FAQ answer appears fairly authoritative:
>>
>> https://www.sqlite.org/faq.html#q5
>
> Interesting.

"Concurrency" is a PAIN IN THE ASS at the programming
level !

The most common solution are uniquely-tagged files/processes
and record-level locking. Alas record-locks DO tend to go
wonky eventually because users find SOME unique way to
screw up. "QuickBooks Multi-User", for example, will go
insane every month or two and you have to reboot the server
to restore multi-user access. Users tried to abort, or
rebooted, in the middle of an update too often and ....

There are also 'all-access' files/records/data-frames which
are "live" ... ie you can be looking at it, able to edit it,
but anything another user does immediately updates YOUR view.
I think WikiPedia is sort-of that way - "dueling editors" is
a thing that CAN happen. Some other "collaborative" documentation
systems are like that too - everybody's live.

On 01/03/2023 06:32, 28A.I873 wrote:
> "Concurrency" is a PAIN IN THE ASS at the programming
>   level !

Which is why things like multi-process/multi-user operating system
developed things like semaphores, messages, queues and database engines.

--
"Strange as it seems, no amount of learning can cure stupidity, and
higher education positively fortifies it."

- Stephen Vizinczey

On 2023-03-01, 28A.I873 <28A.I873@noabzba.net> wrote:

> I've several NON-IT people who were able to create
> and tweak an inventory DB using Access.. pix of
> the hardware included. NONE could do it with
> Oracle/MySql/SQL-SERVER ... no WAY. This means
> that *I* don't have to worry about it, *I* don't
> have to tweak it, *I* don't have to maintain it.
> Does what it needs to do.

And they don't/can't/won't come after you when
things go sideways? You're in an enviable position.

--
/~\ Charlie Gibbs | You can't save the earth
\ / <cgibbs@kltpzyxm.invalid> | unless you're willing to
X I'm really at ac.dekanfrus | make other people sacrifice.
/ \ if you read it the right way. | -- Dogbert, 2007-06-20

On 3/1/23 5:30 AM, The Natural Philosopher wrote:
> On 01/03/2023 06:32, 28A.I873 wrote:
>> "Concurrency" is a PAIN IN THE ASS at the programming
>>    level !
>
> Which is why things like multi-process/multi-user operating system
> developed things like semaphores, messages, queues and database engines.

Yep, lots of tricks (often proprietary to the particular app)

"Database engines" are just a more user-transparent approach
to the semaphores/messages/queues/locks/etc. They all still
DO it, it's just a bit "under the hood".

If you need to write your own DB, even if quite simple, then
YOU have to ensure at least file-level, preferably record-level,
concurrency protections.

On 3/1/23 4:57 PM, Charlie Gibbs wrote:
> On 2023-03-01, 28A.I873 <28A.I873@noabzba.net> wrote:
>
>> I've several NON-IT people who were able to create
>> and tweak an inventory DB using Access.. pix of
>> the hardware included. NONE could do it with
>> Oracle/MySql/SQL-SERVER ... no WAY. This means
>> that *I* don't have to worry about it, *I* don't
>> have to tweak it, *I* don't have to maintain it.
>> Does what it needs to do.
>
> And they don't/can't/won't come after you when
> things go sideways? You're in an enviable position.

Oddly, nothing has ever gone wrong :-)

Access is "simple" enough, and old enough, to be
kinda bulletproof now.

It DOES have its uses.

Unless you're plotting some "job security" complexities :-)

I'm kinda on the way OUT ... so "job security" isn't what
I'm looking for - stuff that can coast a few years ONCE I'm
gone is the ethical thing.

On 02/03/2023 03:48, 28A.I873 wrote:
> On 3/1/23 5:30 AM, The Natural Philosopher wrote:
>> On 01/03/2023 06:32, 28A.I873 wrote:
>>> "Concurrency" is a PAIN IN THE ASS at the programming
>>>    level !
>>
>> Which is why things like multi-process/multi-user operating system
>> developed things like semaphores, messages, queues and database engines.
>
>   Yep, lots of tricks (often proprietary to the particular app)
>
>   "Database engines" are just a more user-transparent approach
>   to the semaphores/messages/queues/locks/etc. They all still
>   DO it, it's just a bit "under the hood".
>
>   If you need to write your own DB, even if quite simple, then
>   YOU have to ensure at least file-level, preferably record-level,
>   concurrency protections.
Yup. TBH that is pretty much all the functionality I expected from
MYSql. It for sure is pretty crap at executing *complex* SQL.

I had written a C program and debugged it and got the answer I wanted
before the SQL query it duplicated had finished...

--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.

On 2023-03-02, 28A.I873 <28A.I873@noabzba.net> wrote:

> On 3/1/23 4:57 PM, Charlie Gibbs wrote:
>
>> On 2023-03-01, 28A.I873 <28A.I873@noabzba.net> wrote:
>>
>>> I've several NON-IT people who were able to create
>>> and tweak an inventory DB using Access.. pix of
>>> the hardware included. NONE could do it with
>>> Oracle/MySql/SQL-SERVER ... no WAY. This means
>>> that *I* don't have to worry about it, *I* don't
>>> have to tweak it, *I* don't have to maintain it.
>>> Does what it needs to do.
>>
>> And they don't/can't/won't come after you when
>> things go sideways? You're in an enviable position.
>
> Oddly, nothing has ever gone wrong :-)

You are _very_ lucky. Whenever I'm in such a situation,
along comes the User from Hell, who messes with the system,
breaks it thoroughly, complains loudly, then clams up when
I ask what he did.

> Access is "simple" enough, and old enough, to be
> kinda bulletproof now.

Apparently it's also user-proof, at least in your case.

--
/~\ Charlie Gibbs | You can't save the earth
\ / <cgibbs@kltpzyxm.invalid> | unless you're willing to
X I'm really at ac.dekanfrus | make other people sacrifice.
/ \ if you read it the right way. | -- Dogbert the green consultant

On 3/2/23 2:06 PM, Charlie Gibbs wrote:
> On 2023-03-02, 28A.I873 <28A.I873@noabzba.net> wrote:
>
>> On 3/1/23 4:57 PM, Charlie Gibbs wrote:
>>
>>> On 2023-03-01, 28A.I873 <28A.I873@noabzba.net> wrote:
>>>
>>>> I've several NON-IT people who were able to create
>>>> and tweak an inventory DB using Access.. pix of
>>>> the hardware included. NONE could do it with
>>>> Oracle/MySql/SQL-SERVER ... no WAY. This means
>>>> that *I* don't have to worry about it, *I* don't
>>>> have to tweak it, *I* don't have to maintain it.
>>>> Does what it needs to do.
>>>
>>> And they don't/can't/won't come after you when
>>> things go sideways? You're in an enviable position.
>>
>> Oddly, nothing has ever gone wrong :-)
>
> You are _very_ lucky. Whenever I'm in such a situation,
> along comes the User from Hell, who messes with the system,
> breaks it thoroughly, complains loudly, then clams up when
> I ask what he did.

Heh heh ... yea, I've had a few of those - JUST enough
knowledge, or perception thereof, to cause LOTS of
damage. Fortunately none of them ever got ahold of
that Access app.

And then there are "cursed" users ... whatever they
touch - software OR hardware - always breaks for no
obvious reason :-)

>> Access is "simple" enough, and old enough, to be
>> kinda bulletproof now.
>
> Apparently it's also user-proof, at least in your case.

The (literal) few that use/tweak it never try to get
TOO deep. They mostly rely on the 'surface features'
and never try to do any actual "programming" - decorate
all those potential hooks. It's enough for what they're
doing. Access CAN get pretty deep, fiddly detailed
code. In truth it's got the POTENTIAL for almost any
kind of use, but once you go THAT far you probably
need another kind of database.

On 3/2/23 4:41 AM, The Natural Philosopher wrote:
> On 02/03/2023 03:48, 28A.I873 wrote:
>> On 3/1/23 5:30 AM, The Natural Philosopher wrote:
>>> On 01/03/2023 06:32, 28A.I873 wrote:
>>>> "Concurrency" is a PAIN IN THE ASS at the programming
>>>>    level !
>>>
>>> Which is why things like multi-process/multi-user operating system
>>> developed things like semaphores, messages, queues and database engines.
>>
>>    Yep, lots of tricks (often proprietary to the particular app)
>>
>>    "Database engines" are just a more user-transparent approach
>>    to the semaphores/messages/queues/locks/etc. They all still
>>    DO it, it's just a bit "under the hood".
>>
>>    If you need to write your own DB, even if quite simple, then
>>    YOU have to ensure at least file-level, preferably record-level,
>>    concurrency protections.
> Yup.  TBH that is pretty much all the functionality I expected from
> MYSql. It for sure is pretty crap at executing *complex* SQL.
>
> I had written a C program and debugged it and got the answer I wanted
> before the SQL query it duplicated had finished...

SQL *can* be VERY clunky (and the syntax can start to
look like Martian). I had an old DOS-era DB that
implemented a fair SQL. However if you went to the
lesser-documented underlying, mostly 'C', routines
you could speed it up by 50 times easily for big
complex search/sorts and such.

IMHO, a "standard" language that quickly becomes
incomprehensible to all but the most dedicated
hacks is a POOR standard. Yea, you can write
horrible 'C' ... but you don't HAVE to (and the
horrors aren't any faster/smaller either). With
SQL you kinda HAVE to write horrors, nested
inner/outer joins are the least of it. I see why
lots moved to Java to do the hard work. STILL
more pretty and understandable than SQL "paragraphs"
(sometimes "novellas").

ANYway, I tend to avoid making 'complex' databases
now. More pain than gain. 99.9% of what any outfit
really NEEDS a DB for can be implemented using
SIMPLE methods and structure. For that MySQL or
numerous others are perfectly good. Now it you're
the DOD or DOE or HS or something, then, well ...

On 2023-03-03, 28A.I873 <28A.I873@noabzba.net> wrote:

> And then there are "cursed" users ... whatever they
> touch - software OR hardware - always breaks for no
> obvious reason :-)

They make great beta testers, though. If your system can
survive an encounter with one of them, it's pretty much
bombproof.

--
/~\ Charlie Gibbs | You can't save the earth
\ / <cgibbs@kltpzyxm.invalid> | unless you're willing to
X I'm really at ac.dekanfrus | make other people sacrifice.
/ \ if you read it the right way. | -- Dogbert the green consultant

On 03/03/2023 04:39, 28A.I873 wrote:
> On 3/2/23 4:41 AM, The Natural Philosopher wrote:
>> On 02/03/2023 03:48, 28A.I873 wrote:
>>> On 3/1/23 5:30 AM, The Natural Philosopher wrote:
>>>> On 01/03/2023 06:32, 28A.I873 wrote:
>>>>> "Concurrency" is a PAIN IN THE ASS at the programming
>>>>>    level !
>>>>
>>>> Which is why things like multi-process/multi-user operating system
>>>> developed things like semaphores, messages, queues and database
>>>> engines.
>>>
>>>    Yep, lots of tricks (often proprietary to the particular app)
>>>
>>>    "Database engines" are just a more user-transparent approach
>>>    to the semaphores/messages/queues/locks/etc. They all still
>>>    DO it, it's just a bit "under the hood".
>>>
>>>    If you need to write your own DB, even if quite simple, then
>>>    YOU have to ensure at least file-level, preferably record-level,
>>>    concurrency protections.
>> Yup.  TBH that is pretty much all the functionality I expected from
>> MYSql. It for sure is pretty crap at executing *complex* SQL.
>>
>> I had written a C program and debugged it and got the answer I wanted
>> before the SQL query it duplicated had finished...
>
>   SQL *can* be VERY clunky (and the syntax can start to
>   look like Martian). I had an old DOS-era DB that
>   implemented a fair SQL. However if you went to the
>   lesser-documented underlying, mostly 'C', routines
>   you could speed it up by 50 times easily for big
>   complex search/sorts and such.
>
>   IMHO, a "standard" language that quickly becomes
>   incomprehensible to all but the most dedicated
>   hacks is a POOR standard. Yea, you can write
>   horrible 'C' ... but you don't HAVE to (and the
>   horrors aren't any faster/smaller either). With
>   SQL you kinda HAVE to write horrors, nested
>   inner/outer joins are the least of it. I see why
>   lots moved to Java to do the hard work. STILL
>   more pretty and understandable than SQL "paragraphs"
>   (sometimes "novellas").
>
Exactly. What I wanted to do was normalise some data that was extremely
un-normalised. It was in fact a correlation between political eras -
parishes boroughs counties and so on, and UK postcodes.

Developing the syntax took several days. Then I started it running.
There was no logging possible on its progress.

So I took a subset of the data and ran it on that. It took ages to
discover the two bugs.

I fixed those and ran it again. This time it looked like - assuming
linear extrapolation on the data set size - , it would run for several
days.

So I put on an old Thinking Cap I had lying around, and worked out how
to do it in C, using custom designed data structures, and logging how
fast it was going as well onto the screen.

A couple of hours later all the bugs seemed yo be out and it ran in
about 2 hours. There were a couple of odd enties due IIRC to apostrophes
in the data (John O' Groats)

But those were fixable manually.

>   ANYway, I tend to avoid making 'complex' databases
>   now. More pain than gain. 99.9% of what any outfit
>   really NEEDS a DB for can be implemented using
>   SIMPLE methods and structure. For that MySQL or
>   numerous others are perfectly good. Now it you're
>   the DOD or DOE or HS or something, then, well ...

Exactly so. What I discovered is that building a database that is fully
normalised is not hard, and it works really well, but one must eschew
complex SQL queries on performance grounds.

Conceptually use of a high level language to do a 'for each in this
table, select from that table' worked far better than some sort of
complex join.

And I also discovered the PHP is utter crap with large data sets. My PHP
now calls a C program to access the database and present the selected
data as an output stream.

In the context of concurrency, I also ran into a weird PHP buffering
issue. . In that an uploaded file to a php equipped web server is
available as a temporary entity, which must be converted to an explicit
file if you want to keep it or access it. Which I duly did before
invoking an SQL command to 'load data file' . Which always failed to
work. Because PHP didn't actually write the file until it exited.

I cannot remember what sketchy sort of kludge I eventually used., It
may well have been a copy file command that finally resulted in it being
written to the OS where the SQL daemon could read it.

--
“People believe certain stories because everyone important tells them,
and people tell those stories because everyone important believes them.
Indeed, when a conventional wisdom is at its fullest strength, one’s
agreement with that conventional wisdom becomes almost a litmus test of
one’s suitability to be taken seriously.”

Paul Krugman

On 03/03/2023 04:08, 28A.I873 wrote:
> On 3/2/23 2:06 PM, Charlie Gibbs wrote:
>> On 2023-03-02, 28A.I873 <28A.I873@noabzba.net> wrote:
>>
>>> On 3/1/23 4:57 PM, Charlie Gibbs wrote:
>>>
>>>> On 2023-03-01, 28A.I873 <28A.I873@noabzba.net> wrote:
>>>>
>>>>>      I've several NON-IT people who were able to create
>>>>>      and tweak an inventory DB using Access.. pix of
>>>>>      the hardware included. NONE could do it with
>>>>>      Oracle/MySql/SQL-SERVER ... no WAY. This means
>>>>>      that *I* don't have to worry about it, *I* don't
>>>>>      have to tweak it, *I* don't have to maintain it.
>>>>>      Does what it needs to do.
>>>>
>>>> And they don't/can't/won't come after you when
>>>> things go sideways?  You're in an enviable position.
>>>
>>>     Oddly, nothing has ever gone wrong  :-)
>>
>> You are _very_ lucky.  Whenever I'm in such a situation,
>> along comes the User from Hell, who messes with the system,
>> breaks it thoroughly, complains loudly, then clams up when
>> I ask what he did.
>
>   Heh heh ... yea, I've had a few of those - JUST enough
>   knowledge, or perception thereof, to cause LOTS of
>   damage. Fortunately none of them ever got ahold of
>   that Access app.
>
When I was developing BIOS software for a PC clone, many years ago, the
company employed loads of students in the vacation to fiddle around
until they broke it. An excellent choice, because students have just
enough knowledge to be really dangerous.

On another occasion, I was called back to fix a problem in some software
I had written,. The girl who was using it said 'its strange, because I
used to get it a lot, but now I hardly get it at all..

That was the killer piece of information. When there was an operator
error, my code went to an error handling routine that handled the error
but left the current file open. DOS, being DOS then ran out of file
handles after about 10 errors....

I had never tested against that..

>   And then there are "cursed" users ... whatever they
>   touch - software OR hardware - always breaks for no
>   obvious reason :-)
>
Worse than that, is the user who knows perfectly well what he did to
break it, but wont tell you because of some sort of pointless pride.

I gave up helping a particular neighbour. He always lied about what had
happened because he couldn't admit he didn't know what he was doing,
which made it impossible to fix the mistakes.

>
>>>     Access is "simple" enough, and old enough, to be
>>>     kinda bulletproof now.
>>
>> Apparently it's also user-proof, at least in your case.
>
>   The (literal) few that use/tweak it never try to get
>   TOO deep. They mostly rely on the 'surface features'
>   and never try to do any actual "programming" - decorate
>   all those potential hooks. It's enough for what they're
>   doing. Access CAN get pretty deep, fiddly detailed
>   code. In truth it's got the POTENTIAL for almost any
>   kind of use, but once you go THAT far you probably
>   need another kind of database.

Exactly so.

--
The New Left are the people they warned you about.

On 2023-03-03 10:36, The Natural Philosopher wrote:
> On 03/03/2023 04:08, 28A.I873 wrote:
>> On 3/2/23 2:06 PM, Charlie Gibbs wrote:
>>> On 2023-03-02, 28A.I873 <28A.I873@noabzba.net> wrote:
>>>
>>>> On 3/1/23 4:57 PM, Charlie Gibbs wrote:
>>>>
>>>>> On 2023-03-01, 28A.I873 <28A.I873@noabzba.net> wrote:
>>>>>
>>>>>>      I've several NON-IT people who were able to create
>>>>>>      and tweak an inventory DB using Access.. pix of
>>>>>>      the hardware included. NONE could do it with
>>>>>>      Oracle/MySql/SQL-SERVER ... no WAY. This means
>>>>>>      that *I* don't have to worry about it, *I* don't
>>>>>>      have to tweak it, *I* don't have to maintain it.
>>>>>>      Does what it needs to do.
>>>>>
>>>>> And they don't/can't/won't come after you when
>>>>> things go sideways?  You're in an enviable position.
>>>>
>>>>     Oddly, nothing has ever gone wrong  :-)
>>>
>>> You are _very_ lucky.  Whenever I'm in such a situation,
>>> along comes the User from Hell, who messes with the system,
>>> breaks it thoroughly, complains loudly, then clams up when
>>> I ask what he did.
>>
>>    Heh heh ... yea, I've had a few of those - JUST enough
>>    knowledge, or perception thereof, to cause LOTS of
>>    damage. Fortunately none of them ever got ahold of
>>    that Access app.
>>
> When I was developing BIOS software for a PC clone, many years ago, the
> company employed loads of students in the vacation to fiddle around
> until they broke it. An excellent choice, because students have just
> enough knowledge to be really dangerous.
>
> On another occasion, I was called back to fix a problem in some software
> I had written,. The girl who was using it said 'its strange, because I
> used to get it a lot, but now I hardly get it at all..
>
> That was the killer piece of information. When there was an operator
> error, my code went to an error handling routine that handled the error
> but left the current file open. DOS, being DOS then ran out of file
> handles after about 10 errors....
>
> I had never tested against that..

I heard of that one. Dos file handle limit.

I have hit it also in Linux, recently, when opening a few firefox
instances (firefox -P someprofile). After three, the last one crashed on
open.

>
>>    And then there are "cursed" users ... whatever they
>>    touch - software OR hardware - always breaks for no
>>    obvious reason :-)
>>
> Worse than that, is the user who knows perfectly well what he did to
> break it, but wont tell you because of some sort of pointless pride.
>
> I gave up helping a particular neighbour. He always lied about what had
> happened because he couldn't admit he didn't know what he was doing,
> which made it impossible to fix the mistakes.

Heh.

>>>>     Access is "simple" enough, and old enough, to be
>>>>     kinda bulletproof now.
>>>
>>> Apparently it's also user-proof, at least in your case.
>>
>>    The (literal) few that use/tweak it never try to get
>>    TOO deep. They mostly rely on the 'surface features'
>>    and never try to do any actual "programming" - decorate
>>    all those potential hooks. It's enough for what they're
>>    doing. Access CAN get pretty deep, fiddly detailed
>>    code. In truth it's got the POTENTIAL for almost any
>>    kind of use, but once you go THAT far you probably
>>    need another kind of database.
>
> Exactly so.

Typically, these type of tools make easy things to be real easy, but
hard things become impossible.

--
Cheers, Carlos.

On 2023-03-03, Carlos E.R. <robin_listas@es.invalid> wrote:

> Typically, these type of tools make easy things to be real easy,
> but hard things become impossible.

I've noticed that more and more software is written this way.
Apple has been the spearhead in this movement, but it's becoming
quite widespread. As long as you stay in the playpen (i.e. only
do the things that are pre-ordained) the system is very easy
to use. But the moment you climb out of the playpen you hit a
brick wall. If it's not in the menus you're out of luck, and
keyboard-based alternatives are discouraged. I'd much rather
have a system that's a bit harder to learn but contains more
flexibility; in the long run, it's actually easier to use.
(Note to designers: ease of learning and ease of use are
not the same thing.)

As an opportunity for thread drift, it's always been a hallmark
of the User from Hell to complain in a way that's terse to the
point of uselessness, i.e. "It doesn't work!" Alas, this mindset
is infecting modern software developers. When an error occurs
nowadays, more and more apps are display a message like
"Something went wrong", without any explanation or error
codes which could help the user - or developer - track down
the problem. Grrrrr...

--
/~\ Charlie Gibbs | You can't save the earth
\ / <cgibbs@kltpzyxm.invalid> | unless you're willing to
X I'm really at ac.dekanfrus | make other people sacrifice.
/ \ if you read it the right way. | -- Dogbert the green consultant

On 2023-03-03 16:58, Charlie Gibbs wrote:
> On 2023-03-03, Carlos E.R. <robin_listas@es.invalid> wrote:
>
>> Typically, these type of tools make easy things to be real easy,
>> but hard things become impossible.
>
> I've noticed that more and more software is written this way.
> Apple has been the spearhead in this movement, but it's becoming
> quite widespread. As long as you stay in the playpen (i.e. only
> do the things that are pre-ordained) the system is very easy
> to use. But the moment you climb out of the playpen you hit a
> brick wall. If it's not in the menus you're out of luck, and
> keyboard-based alternatives are discouraged. I'd much rather
> have a system that's a bit harder to learn but contains more
> flexibility; in the long run, it's actually easier to use.
> (Note to designers: ease of learning and ease of use are
> not the same thing.)

But depends on intended usage and by whom, too.

>
> As an opportunity for thread drift, it's always been a hallmark
> of the User from Hell to complain in a way that's terse to the
> point of uselessness, i.e. "It doesn't work!" Alas, this mindset
> is infecting modern software developers. When an error occurs
> nowadays, more and more apps are display a message like
> "Something went wrong", without any explanation or error
> codes which could help the user - or developer - track down
> the problem. Grrrrr...

Yak.

New camera can, among many other possibilities, "connect to computer via
router wifi". Nice. So camera finds SSID, tell password, wait...
nothing. Camera tries then gives up, no error message.

Grrr indeed.

Suspicion is it wants to find a published shared directory (on samba).
Or maybe not, camera doesn't know workgroup name or password.

--
Cheers,
Carlos E.R.