Latest Contributions by DavidSolari

Edit management is tricky to keep track of in ArcGIS because you have multiple types of "transactions": Database transactions/file locks: These are the fundamental locks that everything else is built upon. Proper databases (EGDBs, File GDBs, Mobile GDBs etc.) can start and stop transactions of various lengths depending on how you edit them, these limit how other users can write data to the same DB while they're in effect. EGDBs run on full relational database engines so transactions are usually kept as short as possible to avoid locking up other users, this is why your ability to save or undo edits are heavily limited when you work with them directly. The file system DBs only allow one active writer so they can keep a transaction going much longer. Other file types try to behave like File/Mobile GDBs by creating lock files during edits if possible. Edit sessions: These open a transaction/lock and only release the lock when you finish your edits. GDBs will keep a stack of your edits to allow you to undo, redo, and fully discard the edits before saving. Other file types are usually more limited in how granular the edit tracking goes. You can also have an edit session with an EGDB, but only if you use ... Versions: Concurrent streams of edits that are merged into one EGDB object. Every individual edit uses a short transaction and the ability to undo/redo/discard involves manipulating the table data through these short transactions, with various version control mechanisms used to isolate these potentially incomplete edits from other versions. This would be the "have your cake and eat it too" option if it weren't for the extra complexity brough by reconciling, posting, conflict detection etc. as well as making the underlying DB tables less performant than a straight list of features. My advice is to avoid thinking of "short" vs. "long" transactions and instead think about how you need to manage a piece of data over the long term: who needs to edit it, do they need to do so concurrently, is it worth giving them access to an undo stack in exchange for adding version management etc. If you field calculate 1 million records directly against an EGDB feature class with no undo enabled you're technically doing a "short" transaction, but you can probably guess that you're locking the database up far longer than if you move one point in a "long transaction" branch version. ... View more

If you're fine going outside of the Survey123 apps you can upload data directly to the feature service that comes with every survey form. Just make sure all your domain codes and whatnot are valid and you can do mass updates in Pro, a web app, etc. etc. ... View more