Access 2002, multiple user access

E

elongp

I read the posts on this topic from 2005 & 2006. What we've been doing is
setting permissions on the .ldb file so it cannot be deleted. That seems to
work pretty well.

We have one division who uses this, but they create new dbs all of the time
or move the original from one directory to another, and of course it no
longer works.

Do you think the db splitter is the way to go for them? I am going to read
Bob Larson's explanation of Access and how the splitting works. If it's not
that difficult, I may do it for them the first time then turn it over to the
users!

Any suggestions?

Thanks,
(Ms) E Long Powell
TX Dept of Ins
Austin, TX
 
W

Wayne-I-M

Hi

Splitting the DB is not going to stop someone from creating new ones or
copying the front end to a new location. You could put secutirty on the back
end - but if they know even a little about how computers work (not access but
computer in general) they will still be able to copy even the BE.

It sounds to me (many people here may diagree with this by the way ) that
this is not really an access problem but a people problem. It seems that you
may just have to go a see the people createing the problems and tell them not
to.

I understand this is some times a problem but it's really the one thing that
will work in the long term
 
E

elongp

Well, it's their data, and if they need to create a new db, who am I to stop
them. Thanks for suggesting it, though. It would just not work with this
group.

What is the general opinion of locking the .ldb from being deleted?
 
G

Guest

What is the general opinion of locking the .ldb from being deleted?

I think it's a reasonable idea, but it is quite uncommon.

Some history:

1) Access 2.0, running on Windows 3.11, had a problem
if Access, Windows, or your Computer crashed. The problem
was that the LDB was left with an uncompleted transaction,
and needed to be reset before it could be used again.

2) Access 2.0, Win 3.11, ran slowly and took a lot of memory
on computers of the time. We used to have reports that took
an hour to run! (People were pleased because they replaced
reports that took people a week to compile).

3) Access 95 was a dog, and crashed a lot.

In Access 98, a solution to these three problems was to delete
the .ldb file when you closed Access.

1) If the ldb is missing, you can create a new one with no broken
transactions.

2) If the ldb is missing, you know nobody else is using the
database, and you can use a new, faster, 'exclusive mode'

3) You can delete the ldb if it gets corrupted.

None of these reasons particularly apply to you, as you have
seen. If you do have problems with a corrupt LDB, or if you
want to run in 'exclusive mode', then you need to delete the
LDB. Otherwise, deletion is just a historical oddity.

(david)
 
T

Tom Wickerath

Hi David and Ms. E Long Powell,
I think it's a reasonable idea, but it is quite uncommon.
Click to expand...

I don't think this is a good idea. You can use Windows to remove delete
permissions on the .mdb file itself, but you should allow the .ldb file to be
deleted. See the article below that I provided a link for.

In Access 98, a solution to these three problems...

Otherwise, deletion is just a historical oddity.
Click to expand...

I disagree. Access is designed to delete the locking database file when the
last user exits the application. If this file is not automatically deleted,
this can be a sign of corruption. More information here:

Introduction to .ldb Files
http://support.microsoft.com/?id=299373


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
T

Tom Wickerath

Hi David,

Take another look at KB 299373 (http://support.microsoft.com/?id=299373).
This includes the following quote:

"Whenever the last user closes a shared database, the .ldb file is deleted.
The only exceptions are when a user does not have delete rights or when the
database is marked as corrupted."

Do you really want to remove the canary from the coal mine, thus losing an
early indicator of possible database corruption? Iwouldn't. While this
doesn't prove anything, I think it follows best practices to let Access work
as it was designed to work. Your choice, of course. For me, I'll choose to
retain the canary as an early indicator of problems.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
G

Guest

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)
 
T

Tom Wickerath

Hi David,
You have got the next bit a little bit the wrong way around.
Click to expand...

With all due respect to you, and your long history using earlier versions of
Access, I do not believe I have it wrong.
Deleting the ldb doesn't expose corruption, it hides it.
Click to expand...

I do not agree. According to Microsoft, the INABILITY of Access to delete
the locking database file is a sign of possible JET database corruption, ie.
"...when the
database is marked as corrupted." Don't misread this statement by making the
assumption that as long as the .ldb file is always deleted automatically, the
database is corruption free. It doesn't say that. It simply says that when
the database is MARKED as corrupt, the .ldb file is not deleted. If you are
intentionally preventing the automatic deletion of the .ldb file, then you
simply will never see this early warning sign of potential corruption.

I didn't misread anything. I believe you have, but I'm also not going to
waste my time trying to convince you further.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
 
E

elongp

So I guess in response to my original query =- ) locking the .ldb, or
preventing it from being deleted, is not the ideal way to share a db with
multiple users. I will pass on that information giving them the front
end/back end options talked about in these posts.

Thanks,

E Long Powell
Austin, TX
 
A

Alan

Hi David and Ms. E Long Powell,



I don't think this is a good idea. You can use Windows to remove delete
permissions on the .mdbfile itself, but you should allow the .ldb file to be
deleted. See the article below that I provided a link for.




I disagree. Access is designed to delete the locking database file when the
last user exits the application. If this file is not automatically deleted,
this can be a sign ofcorruption. More information here:

    Introduction to .ldb Files
   http://support.microsoft.com/?id=299373

Tom Wickerath
Microsoft Access MVPhttp://www.accessmvp.com/TWickerath/http://www.access.qbuilt.com/html/expert_contributors.html
__________________________________________
















- Show quoted text -
Click to expand...

Hi,

Perhaps you need to recover the database if necessary. You may try
Advanced Access Repair at http://www.datanumen.com/aar/ This tool is
rather useful in salvaging damaged Access MDB files.

Alan
 
E

elongp

Thanks for all of your input. There is nothing wrong with any database. I was
asking opinions on how to best share a network db. Our user is asking for an
easier way than locking down the .ldb. I don't think they'll go for splitting
and making an mde, and I will suggest it.

Thanks!

E Long Powell
Austin TX
 
D

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)
 
E

elongp

There are no problems. Some people only have read permissions on the folder,
so we have to remove delete permissions so multiple people can access the db.
They complain because when they copy or move the db, it breaks the
permissions. Again, thanks for all of the input. I have the suggestions to
offer.

No further discussion needed, unless you guys want to virtually duke it out
some more! =-)
 
Top