1

I am in charge of an ArcSDE with my Municipality with a large amount of data over 300+ separate files. I have multiple departments that have access to this ArcSDE with multiple users in each department. No users besides myself and one other (my associate) edit any information. Everyone else is only viewing the data (in ArcMap).

My problem is that when it comes time for myself or my colleague to make edits or perform file property changes (add domains etc.) to files, the files are being used by other users (usually more than one) which cause file locks.

I want to know how I can still make these edits/ file changes while other users are still viewing the files. I have proposed that when these file locks occur I ask the users to exit out of ArcMap the only issue is some users have very old PC's and the start-up time for these MXD's can be very long and asking them to boot off ArcMap multiple times a day is not a reasonable request. It would be ideal for me to be able to make my desired edits while other users are reading the files and these files would update for the user once they exit out and reopen the file connection to the ArcSDE. So basically while reading the file nothing changes (even though I made edits while they had the file open) until they close ArcMap and re-open it.

Any information at all regarding this topic?

UPDATE

I have been doing further research and it seems that I need to further look into versioning. However not sure the structure of the ArcSDE was configured in when it was originally configured (if that matters). If anyone else has some experience with this and could give me some insight on how going about this, or am I even heading toward the right direction?

  • 6
    Data is never "in" SDE -- It's in a database (the version of which you should mention). The objects are not "files", but tables (which the geodatabase model calls "feature classes"). Editing rows ("features") should be possible without lock conflicts, but editing the table structure ("feature class properties") is forbidden while other users are accessing the tables. It sounds like your enterprise geodatabase is operating exactly to design. Most organizations schedule an "outage window" where these sorts of changes can be implemented. – Vince Dec 2 '16 at 22:04
1

I designed and Implemented a new Versioning Workflow to hold data integrity (we will soon has a huge number of field crews for departments who will be inputting data from the field [could lead to incorrect inputs]). This multi-tier version workflow will only allow lead-users to Post edits to the parent versions.

The example is below.

SDE Version Workflow

1

Versioning will not help you with this, if you're making schema changes (eg, adding domains, deleting fields, feature classes, etc). For schema changes, there must be no users accessing those data sets even if the datasets are versioned.

Also, you can make normal data edits (of the values within fields/attributes) while people are using those datasets whether it is versioned or not. Again, versioning will not help you here.

For making schema changes in the database, you should be scheduling an outage window - preferably outside of working hours. All users should be notified well in advance of when this will occur and you should force all users to log off at the start of that time period. This may require you to batch all your schema changes so that they can all be done at once, rather than ad-hoc at different times during the day. You can even use a script or a model to run the schema changes (after testing it on a copy of the database in a 'development' or 'testing' environment). Your script/model can include the command to force log off users at the beginning.

(The problems that versioning solves are a different set of problems. In particular, versioning allows multiple editors to change the same data at the same time, and provides a way to manage conflicts that may arise between such edits.)

For the record, at my workplace, every editor has their own version, and they are only permitted to post their edits to the 'QA' (quality control) version. From there, we have an automated script that posts 'QA' changes to the 'Default' (master) version. With all this versioning, we still cannot make any schema changes while people are using the affected datasets, due to locking. In order to make such schema changes, even with versioning, we have to make sure all users are logged off, and that any services using those datasets are stopped (although in general, we run services off of a fGDB replica, not directly off the SDE).

  • Thank you very much, I have realised that schema changes will not work with versioning if someone is already accessing the same files. The outage-window will be my solution to this. In regards to versioning our City is about to go through a tremendous data and infrastructure update which we will have many field crews performing live edits in the field so multiple versions is crucial for this to ensure data integrity. Thank you for your time on this answer it actually made a lot of sense and will definitely help out in the coming weeks! Cheers – NULL.Dude Dec 9 '16 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.