Well it says it right there: the exception is when the user does
not have delete rights.

You have got the next bit a little bit the wrong way around.

Deleting the ldb doesn't expose corruption, it hides it.
As the reference points out, when the ldb is NOT deleted
you can see some history in it.

So automatic deletion of the ldb is not the "canary in the coal mine"

A true point is, and was, that deleting the LDB allows you to
delete hanging locks (hide the problem).

This was never more than a side issue to the real question,
which was asked all the time, over and over, by thousands
of new users: what are all these LDB files? Where did they
come from? Are they safe to delete? Do I have to back them
up? Why does MS create these annoying files? Why doesn't
MS delete these annoying files after they are no longer required?

And, as I mentioned before, the other reason for LDB deletion
is to support "exclusive mode" -- which I have NEVER seen
used with a split FE/BE system, so unless you are very unusual,
or you don't recommend FE/BE (!) there is the most important
reason for deleting the LDB gone.

Of course Jet "exclusive mode" predates modern Windows
network optimisations, which support exclusive mode
underneath Jet even when Jet is in shared mode.

The next objection is "let Access work as it was designed to work"

My disagreement with that is that I've been around long
enough to remember the way that Access was designed
to work. It wasn't designed to delete the ldb.

Deleting the ldb makes Jet slower to open, and slower to
close. It's a kludge to make exclusive mode work (no longer
required), and a kludge to work around the instability of
Win 3.11 and A95, (no longer required), and an important
marketing kludge, and it was tacked onto the Jet engine by
the people who gave us Jet 3.0.

But I'm not saying that's a definitive argument: normally you
don't need to see what's in the ldb, so it's safe to delete it,
and sometimes you do want exclusive mode (for compact
and repair) so you need to delete it, and there is a work-around
for the slow-open problem.

So although I don't have any objection to people removing
the delete permission for ldb files, I'm not a proponent
either. It's another situation where the default behaviour
is correct for most new users.

(david)

While it's a good idea, I'm not sure that splitting and making an MDE
will solve any problems they have, if they are having any problems.

Why are they removing delete permission from the ldb?

So that the new ldb is not created with the wrong permissions?
Because you don't have create permission in the data folder?
In that case, the standard procedure is to set the default permission
for the data folder, so that ldb's are created with the correct
permission.

So that that the mdb can be opened and closed faster?
In that case, removing the delete permission is an advanced option,
for people who have already considered other options.

Because you have users opening the mdb in exclusive mode?
That would be fixed with a FE/BE split, but another option
would be to remove the open/exclusive permission from the
default user inside access (Access has a whole parallel set of
internal permissions, because it predates Windows permissions).

(david)