Working with GIS data on Network Share

6696
14
Jump to solution
07-26-2019 06:50 AM
MalcolmMeyer2
Occasional Contributor II

Hey Ohio GIS community - what is your workflow for working with GIS data that is stored on a network share. I am not talking about data stored in an enterprise database or workgroup database. I am talking shapefiles, file geodatabases, or personal geodatabases. I have recently been told by Esri support, after encountering some data corruption, that editing file geodatabases off a shared drive is not recommended.

File geodatabases are not recommended to be stored on network drives, and two or more users simultaneously viewing/editing a feature class within the database can easily create a wide range of issues...I would suggest that you copy the file geodatabase onto a local drive on your machine, or onto a SQL Server express database...

see - https://community.esri.com/thread/221282-file-geodatabase-in-windows-networks-very-poor-performance


Has anyone found one of the three data storage types listed above more reliable than others? It looks like my only avenue until I get SQL Server Express up and running on the network would be - 

  1. Copy data to local drive
    1. This now means that I have one MXD linked to local data, and the viewer MXDs that are stored on the network linked to network data, unless I completely recreate the server file structure on my local machine, thus allowing relative paths to work for both MXDs.
  2. Make Edits
  3. Verify all Arc sessions are closed and copy the data back to the server
    1. Unless I do this daily, I have to then create a backup plan for my local data and MXDs (the server is already backed up)
    2. Scripting this will not work as I have to first verify all Arc sessions are closed and no lock files are present
14 Replies
MalcolmMeyer2
Occasional Contributor II

Great, this is the type of information that is helpful. Especially this - might have to look into this for our use case:

The network shares are flagged read only for all authorized users with the exception of two users that have full access for editing.  This prevents lock files from being created on the fGDB files by users only accessing to read the data.

0 Kudos
ScottFierro2
Occasional Contributor III

I'd agree with Lance. Have done similar workflows and in the same manner. No lock files to date inside fGDB's just enterprise GDB's.

0 Kudos
MalcolmMeyer2
Occasional Contributor II

So in your case and in Lance your case, all your editing is done in an Enterprise GDB, and you are just using the fGDB for viewing, with the directories set to read-only? Is that correct? This might be the option I go for moving forward.

0 Kudos
ScottFierro2
Occasional Contributor III

We do have fGDB's out on the shares people do edits and GP's against but it's all super granular locked down within NTFS. Use a series of AD groups to completely hide things away from all but a select few, to something wide-open for all in the organization to view. So many different workflows and options that may dictate what we do with 1 fGDB over to the next. Yes in general, 90% or more of activities we do are in enterprise GDB's.

0 Kudos
LanceCole
MVP Regular Contributor

The fGDB files are archived data, data we receive regularly from other agencies or third parties that are used to update our enterprise GDB, temporary files when working on new feature sets or classes as modifying enterprise GDB schemas can be a pain during normal business hours, a few datasets we just do not want to add to our enterprise deployment, quick onetime projects,  etc.  We still do edit some of these files but only by a handful of people.

We also have the a separate folder on the share for shapefiles.  However, all our shapefiles are immediately imported into various fGDB or our enterprise GDB as feature classes for use internally.  Well, they are suppose to be anyway.  Working with shapefiles as part of your normal workflow is not their intended function.

To answer your question, I would say 70-80% of our editing is performed in the enterprise environment.  The remaining portion is using fGDBs.

0 Kudos