I'm not seeing this functionality in the Quartz SDK. Am I just missing it? Will it in the final release? If not, is there a recommendation or best practice from Esri for performing a series of edits as a transaction?
Solved! Go to Solution.
We do plan on supporting transactions, but we haven't been able to get to it yet unfortunately.
Can you describe your workflow where it is needed?
We do plan on supporting transactions, but we haven't been able to get to it yet unfortunately.
Can you describe your workflow where it is needed?
Our users go through a series of editing views to update attribution on tables as well as create and update geometries for feature classes. When they're finished with the process, we need to save all of those updates as a transaction otherwise we risk corrupting our database. We don't use esri relationship classes but we do have relationships in our database that we must maintain. In our largest workflow, we have 5 tables and one feature class that all need to be saved at the same time, as one transaction.
If you don't mind me asking - what is it about the data that requires you to save everything at the same time?
Could you persist some data throughout the editing view workflow to make sure everything is saved with the correct foreign keys in place to maintain your relationships?
I have multiple records that together make up one transaction. If I insert three records but the fourth fails, then I have situation where I have an incomplete data or orphaned record. Saving the records and maintaining relationships is not the issue. The real problem is that I want either all of my records in the database or none at all.
Ahh - gottcha... what is the source of the failures? In my experience these are pretty infrequent once you get past the typical development issues.
You could chain the database saves together and roll them back manually if one fails -- basically delete the previously saved features if you hit an issue.
They are infrequent but if it happens once in production then we have a problem. I've considered the approach you described, and it's certainly an option, but it would require bookkeeping for all create/update/delete operations which I would like to avoid. More importantly, if one of these manual rollbacks fails then we're still in a situation where we have corrupt data.
Divesh Goyal Ryan Olson Any update on this? Any chance this will be in the next release of the SDK? Thanks!
No, it is not in v100. Looks like it might make it into an update in the future, probably not the next one.