Database Lock Protocol Error:

2888
6
Jump to solution
10-05-2015 01:40 PM
JeremyMullins1
New Contributor III

Our company creates an app that allows the client to store the runtime content on their server for multiple users to access at the same time. However, when first providing the clients with the data, we get random errors at different sites. We generally use four layers (four geodatabase files) - at every site one or more of these layers will give the error Database Lock Error Protocol:

It's never the same layers and all users on every server have full control (read/write access); however, after about 1 - 2 days of deployment, the errors disappear altogether, never to return. We thought it was because multiple users were accessing the data at the same time, but if that's the case, why would only one or two layers show this error and not all 4 four? Why would it then disappear with no subsequent signs of similar errors?

We want to be able to identify what causes this and haven't been able to pinpoint it. Does anyone have any idea what could be causing this?

0 Kudos
1 Solution

Accepted Solutions
MichaelBranscomb
Esri Frequent Contributor

Hi,

Unfortunately in the current release (10.2.6) sharing mobile geodatabases on file servers is not supported - they must be local to the client machine because they open in the Sqlite WAL mode which is not supported on network fileshares.

We will investigate how we can support this workflow in future.

Cheers

Mike

View solution in original post

6 Replies
MichaelBranscomb
Esri Frequent Contributor

Hi,

Can you describe your exact workflow for generating the database and how you make it available on the server?

Cheers

Mike

0 Kudos
JeremyMullins1
New Contributor III

Michael,

Absolutely, and thanks for the quick response. Hopefully my detailed process will help.

Different customers provide me with shapefiles (streets, land use, address points, hydrology, zones, etc.) which I then convert into feature classes within feature datasets in a file geodatabase I create on a VM where I have ArcGIS Basic installed. From there, I create four basic map documents: Basemap, Streets, Structures, and Zones. Each map document contains basically the exact same feature classes, just for that particular customer (lakes, streets, houses, various businesses, etc.) From there, I simply save the map document and share as runtime content. I store it all in a single folder.

The folder will contain the four subfolders housing their particular .geodatabase file (so Basemap, Streets, Structures, and Zones). This, along with a created .json file that our app uses to display the runtime content is placed on an customer's server. We create many other applications (not ArcGIS-related) that require users to have full control of the drive and its subfolders in order for those applications to work, and these folders are stored on the same drive. We then create a .bin file that directs to the .json file (which itself points to the individual .geodatabase files).

From there the user, from their local machine, access the server where the application (and associated map data) is stored. When we use this process in-house, we cannot replicate the errors that occur. I will load up mapping application from two different servers, and while the applications are both pointing to the same location where the .geodatabases are stored (on a third server), again, no errors occurred. We have verified that all the permissions are correct for the users.

I hope this helps.

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Hi,

I've asked our geodatabase guys for their input on this, I'll update this thread as soon as i have more info.

One thing [un-related to this issue]... I recall being told some time ago that you should only use feature datasets if you need the additional geodatabase behavior they support such as network datasets or geometric networks. Otherwise you should keep your feature classes at the root level. Apart from the fact that all feature classes in the feature dataset become locked when you start editing one, there may also be a memory overhead. I don't know if that's still true, but any chance to optimize performance is worth investigating.

Cheers

Mike

0 Kudos
JeremyMullins1
New Contributor III

Michael,

Thanks! I will update my notes here and await your reply. As far as the feature datasets go, we are in the process of trying out network datasets for our customers, so that is the reason why I went ahead and put everything in feature datasets. However, I can create a separate file geodatabase of just feature classes and work with that - as you say, it's definitely worth investigating.

Thanks again.

0 Kudos
MichaelBranscomb
Esri Frequent Contributor

Hi,

Unfortunately in the current release (10.2.6) sharing mobile geodatabases on file servers is not supported - they must be local to the client machine because they open in the Sqlite WAL mode which is not supported on network fileshares.

We will investigate how we can support this workflow in future.

Cheers

Mike

JeremyMullins1
New Contributor III

Michael,

Thanks for taking the time to look into this.

Jeremy

0 Kudos