UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Unable To Lock File, Access 2016    
 
   
airplayne
post Apr 16 2018, 08:42 AM
Post#1



Posts: 507
Joined: 17-February 09
From: California


I have some users getting the above error message when they attempt to open a database I built. Any thoughts on why this would be? I have confirmed they are able to open other files in the folder and drive on which this database resides, they are just having issues with this specific database, as far as I can tell.
Go to the top of the page
 
GroverParkGeorge
post Apr 16 2018, 08:43 AM
Post#2


UA Admin
Posts: 32,372
Joined: 20-June 02
From: Newcastle, WA


How are they trying to open it? Does someone have it opened in Exclusive Mode?

--------------------
Go to the top of the page
 
airplayne
post Apr 16 2018, 11:53 AM
Post#3



Posts: 507
Joined: 17-February 09
From: California


Not from what I can tell. All they are doing is navigating in the file explorer to where the database is housed. Double click on it and as Access is opening they get the error.
Go to the top of the page
 
GroverParkGeorge
post Apr 16 2018, 12:25 PM
Post#4


UA Admin
Posts: 32,372
Joined: 20-June 02
From: Newcastle, WA


Is there a locking file for that database in this folder? If so, can you delete it?


--------------------
Go to the top of the page
 
airplayne
post Apr 16 2018, 12:31 PM
Post#5



Posts: 507
Joined: 17-February 09
From: California


There is when the database is open, but is auto-deleted when it is closed.
Go to the top of the page
 
jleach
post Apr 16 2018, 12:58 PM
Post#6


UtterAccess Editor
Posts: 9,896
Joined: 7-December 09
From: Staten Island, NY, USA


They're not sharing the same database file are they? (you have a split application with a shared BE that's accessed indirectly by the FEs, and each user has their own copy of the FE?)

--------------------
Go to the top of the page
 
airplayne
post Apr 16 2018, 01:02 PM
Post#7



Posts: 507
Joined: 17-February 09
From: California


Nope. One single database file. I wasn't planning on splitting this one as it is not that big.

I have never run into this problem before, even with databases I have split. Multiple people have always been able to access the front end, or just the single database file at the same time. Is there a setting in the options of the database I am overlooking, or could this have something to do with the share drive settings?
This post has been edited by airplayne: Apr 16 2018, 01:04 PM
Go to the top of the page
 
John Vinson
post Apr 16 2018, 04:03 PM
Post#8


UtterAccess VIP
Posts: 4,213
Joined: 6-January 07
From: Parma, Idaho, US


These days, one record and two users is big enough to split. It's really NOT optional with recent releases of Access.

--------------------
John W. Vinson
Wysard of Information
Go to the top of the page
 
John Vinson
post Apr 16 2018, 05:56 PM
Post#9


UtterAccess VIP
Posts: 4,213
Joined: 6-January 07
From: Parma, Idaho, US


Users will need full (read, write, create, delete) privileges on the FOLDER in which the database - or the backend, if it's split - resides to be able to create and delete the lock file.

--------------------
John W. Vinson
Wysard of Information
Go to the top of the page
 
GroverParkGeorge
post Apr 16 2018, 07:12 PM
Post#10


UA Admin
Posts: 32,372
Joined: 20-June 02
From: Newcastle, WA


Let me say, at the risk of piling on, this database, like ALL Access database applications, needs to be split. Users should have a personal copy of the FE on their own computers. Only the BE is shared in a network location.

Until this is fixed, problems--like this one--are hovering around your head, waiting to descend in a cloud of rain and lightning.


--------------------
Go to the top of the page
 
airplayne
post Apr 17 2018, 11:29 AM
Post#11



Posts: 507
Joined: 17-February 09
From: California


Hmmm, in the past when I have split databases I have just kept both the front and back end files in the same folder on the network. This allowed me to make changes to the front end without having to send out new copies to everyone who might have one. Haven't had a problem with that, thus far.

Though, I think my real problem with this one is stemming from how people are connecting to the company share drive and whether or not they have read/write access.
Go to the top of the page
 
tina t
post Apr 17 2018, 02:24 PM
Post#12



Posts: 5,340
Joined: 11-November 10
From: SoCal, USA


QUOTE
Hmmm, in the past when I have split databases I have just kept both the front and back end files in the same folder on the network. This allowed me to make changes to the front end without having to send out new copies to everyone who might have one. Haven't had a problem with that, thus far.

that's kind of like saying "When I want to cross the street, I just step out into traffic and rely on all the drivers braking for me. So far, everybody always has." that works fine, until you suddenly become a big splat mark in the middle of the road. it's not really a question of if, but when. a more succinct comparison might be "playing Russian roulette."

when you come to a technical forum for help and advice, and numerous experienced developers tell you the same thing, it's probably a good idea to pay attention. on the other hand, it's your data and your database...and your mess to clean up, so do what suits you, of course.

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
GroverParkGeorge
post Apr 17 2018, 04:24 PM
Post#13


UA Admin
Posts: 32,372
Joined: 20-June 02
From: Newcastle, WA


tina has put it as well as it can be stated.

Sharing a single FE among multiple users is just plain bad juju. Even if you do get away with it, you're investing a limited resource-- luck -- in something that could easily be avoided.

--------------------
Go to the top of the page
 
John Vinson
post Apr 17 2018, 05:16 PM
Post#14


UtterAccess VIP
Posts: 4,213
Joined: 6-January 07
From: Parma, Idaho, US


The read/write access issue will fix this particular error.

However, I agree with my colleagues here - it will NOT fix the very real risk of permanently and irreversibly corrupting your database.

Your choice!

--------------------
John W. Vinson
Wysard of Information
Go to the top of the page
 
airplayne
post Apr 18 2018, 07:00 AM
Post#15



Posts: 507
Joined: 17-February 09
From: California


Generally I will keep a "development" copy in my personal drive of the front end.

A bigger database that I have been maintaining for the past few years I would routinely backup the backed in a separate folder than the original when it gets to a certain size then compact and repair it. I would run updates through it every day so it would rapidly balloon up if I don't watch it.

The one I have now isn't really critical as it is just a study aid for an assessment we have to do for work, so it is easily rebuildable if needbe.
Go to the top of the page
 
GroverParkGeorge
post Apr 18 2018, 08:26 AM
Post#16


UA Admin
Posts: 32,372
Joined: 20-June 02
From: Newcastle, WA


As John said, it is your choice. And by now it is indeed, a choice, a deliberate choice.

--------------------
Go to the top of the page
 
airplayne
post Apr 18 2018, 12:26 PM
Post#17



Posts: 507
Joined: 17-February 09
From: California


Ok, speaking toward the functionality of that approach, how do you handle version control? Meaning, if you make changes to the front end how do you ensure everyone who has a copy has the most current one? Our IT department has a system that pushes updates out automatically on applications they are required to maintain, but I don't think I would be able to set that up on my level.
Go to the top of the page
 
tina t
post Apr 18 2018, 12:57 PM
Post#18



Posts: 5,340
Joined: 11-November 10
From: SoCal, USA


i use Tony Toews' Auto FE Updater, which can be bought on the internet. i think there is also at least one roll-your-own code example in the code archives on this website.

hth
tina

--------------------
"the wheel never stops turning"
Go to the top of the page
 
jleach
post Apr 19 2018, 08:30 AM
Post#19


UtterAccess Editor
Posts: 9,896
Joined: 7-December 09
From: Staten Island, NY, USA


The basic workflow looks like this:

1) Add the latest version to a distribution folder on the server
2) Give the users a small launcher file as their desktop icon (most people use an accdb, but could be script file also, or whatever else)
3) The launcher looks at the local copy (if any) and the latest distribution copy to determine which is higher in version
4) If the server distribution folder has a higher version, it copies the new FE from the server to the local system
5) The launcher fires up the latest copy on the local system (which may or may not have just been updated)

Sometimes it's nice to have some code in the actual FE that verifies compatibility. For example, if you make an update to the BE and requires users must update to the latest FE, you can put a MinimumSupportedVersion in the BE which the FE can check against.

Anyway, there's a whole bunch of possible workflows and the whole thing can get fairly complex depending on what you want to do with it.

Tony's AutoFEUpdater has been a favorite of many Access developers for many years.

--------------------
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    22nd April 2018 - 05:42 AM