Select to view content in your preferred language

Unversioned Database Editing & Issues

11-15-2017 11:39 AM
New Contributor II

I started with a new GIS team that just recently changed the geodatabase from versioned to unversioned (non versioned) to accommodate the massive number of users.

This has created issues with my GIS team locally that are making edits to the data. The main issue is there is no Undo or availability to go back when you accidently move or delete something. The only way to go back is to not save the edit session or in the case you saved the edit session you must use an archive.

Is it possible for my team to make edits to the unversioned geodatabase with the ability to undo mistakes or changes while still editing the same main data on the unversioned database? Does anyone have any tips or things that would help us as we start using a non versioned database?

Any knowledge, tips, tricks, personal experiences on using nonversioned, ANYTHING would help me wrap my mind around using this database and how I can help my team transition to unversioned.


6 Replies
Esri Notable Contributor

GeodatabaseArcGIS EnterpriseManaging Data

This is from the help documentation on A quick tour of working with nonversioned data—ArcGIS Help | ArcGIS Desktop 

Editing nonversioned data that is stored in an enterprise geodatabase is the equivalent of performing standard database transactions. You perform a transaction within the scope of an ArcMap edit session. You start the edit session and perform the required operations, such as adding, deleting, or moving features and updating attributes. When you save your edits, the edits you made are committed to the geodatabase as a single transaction. If you don't want to commit the changes to the geodatabase, you must quit the edit session without saving. This eliminates all the edits you made since you opened the edit session or since your last save. Each transaction can include as few or as many operations as required, provided they fall within a single edit session.

When you edit nonversioned data in an ArcMap edit session, you edit the data source directly; nonversioned edit sessions do not store the changes in other tables like versioned edit sessions do. This avoids the overhead of managing these extra tables and allows you to easily adapt third-party applications so that they can read and edit the data. However, the drawback is that since you edit the data source directly, you cannot undo or redo an individual edit if you make a mistake. The only way to undo edits is to undo all edits by quitting the edit session without saving.

--- George T.
New Contributor II

Yea I understand that. I guess I was just thinking over the reasoning. I know you can manually create a version for editing and I didn't know if that was a way to manually create a version for your edit session and then once your done publish your edits to the unversioned database. I guess the way I think about it is that since you can back out of an entire edit session since it was not saved, the edits were being tacked by the software in some way and caching the changed temporarily. It just seems like an issue and when in an edit session undo should have the ability to be done or temporary versions could be created and used back to the database like I mentioned.

Thanks for the help.  This change is very new and I am still learning about the changes.

0 Kudos
New Contributor III

In a FGDB, that is indeed the case. You can undo because there is some sort of "tracking" that is happening. However, in SDE, edits are committed in batches (every time you save). In a versioning environment, the data exists in a couple of tables, and the database has to maintain all of those tables (hence the extra overhead). So when you add a record, a record is added to the "Adds" table that is associated with the base table of your data.

When you compress the database, it takes all of those adds/deletes from the delta tables and commits everything to the base table. That's why it's important to compress your database regularly in a versioned environment. Check out this link if you want to understand this better. It's a great site: Versioning for Dummies: Part 1 | SSP Innovations 

As for your situation, you'll likely want to have two SDEs. One database for edits (maintenance dB), the other one for publishing. It'll be synched through a replication process (one-way). But even for this, the source has to have versioning enabled for it to work.

MVP Emeritus

You may want to try you post ( Moving Content‌ ) to one of the spaces George mentioned above since htis is not really related to Online.

Are there that many people editing the data at the same time?  Or are there just a handful of users editing and the rest of are read only?

Have you thought about replication (maybe two way if many editors...or one way for read only).  Maybe not a version for each user, but at least one QAQC version that users edit so at least you have one "undo" spot if it it goes really wrong.  Just some thoughts. 

Personally, we only have 2 users that do editing on our files (versioned, topology, archiving) and for all other users, we create copies of one-way replications....including for ArcGIS Server services. We do this about every 2-3 weeks, depending on the edits and only once they have been reconciled and posted, etc.  Then I have a python addin that I use for the AGS prep, etc.  But we are lucky that the services do not need to show changes instantly.  In that case, our workflow may not work for you.


BTW - we add and delete our version (after R&P) often so we can compress and get back to state zero.  If you havein'g taken the coure on working with multi-user databases (that's not quite the right name) or watched some tech sessions on it, I would recommend doing that.  I can get the exact name of the course if needed (and there is a "resource list" for the class I think).

0 Kudos
New Contributor II

Thanks. So your database is nonversioned?

0 Kudos
MVP Emeritus

Our SDE is versioned.  But we just keep the number of versions to a minimum.  Only two of us access the SDE database direct for editing, etc.  All other access thru a FGDB or thru services. 

For reasons that are probably not the same for your case, with my python scripts, I actually make a copy of the 3 "master" feature classes from our SDE database (from Default, after rec and post, etc) to a new FGDB, and then the rest of my scripting re-assigns all the domains (I have 25+), subtypes, etc., then creates new feature classes based on various query combinations that are easier for AGS and the non-GIS staff to use and understand (although they could access the full masters in the fgdb if needed).

I also have a script the full simplify to shape files and .zip them up....these would be for public distribution. fwiw.

edit:  link to the class resources