[Arcgis 101 Full Version Free Download With Crack
Virginie Fayad
Probably just missing a step, but I keep missing it consistently. I have a Traditional versioned dataset in our Portal. The Web Map and layers is configured for sync with a version per user. Creating offline area, editing and syncing all works fine. But when I go to delete the version created for this user I get the error "Operation not allowed on a version with dependent children." I know how to fix this in the SQL Server backend, by manually deleting all the dependent children first. But am I missing a step in a typical offline editing process? thanks!
Posting a final follow-up. I submitted a support ticket with Esri and went all the way through a number of very helpful support departments from Field Maps to Enterprise, finally landing on the SDE / DB team. This is a synopsis of how far we got.
It seems like my process is generally correct, but somewhere along the way when I remove an Offline Area from Field Maps the action to remove the child SYNC versions of the offline editing version is not making it to the back-end and so those child versions are not being deleted.
ArcGIS Pro only displays the main offline edit version, a child of DEFAULT, but does not display the other children of that version. Trying to delete the main offline edit version results in the `160361: Operation not allowed on a version with dependent children.` error, which is recognized but has no solutions, here.
So the only solution we could identify was to access the SDE_VERSIONS table in the back-end DB and manually delete the dependent children of the main offline edit version. So in the screens below version_id = 173 is the main offline edit version that is visible in ArcGIS Pro and which cannot be deleted in Pro. The additional SYNC versions below that are all children of that version and these are not visible in ArcGIS Pro. These versions should be deleted when the Offline Area is removed, but for some reason in my workflow that is not always happening.
So. I manually, and carefully, write out the DELETE statement for each of the child versions, double checking that it is part of the version tree of version_id = 173. Extreme caution here since this example on our dev environment is relatively easy and there are no other versions happening at the same time. In production, it is more likely that there are other versions mixed in among these, so it is an arduous task. Obviously be careful here because DEFAULT is right there! So we felt there was no "smart" SQL statement way to perform this, no range or JOIN, and that each WHERE should be typed out manually and deliberately.
With the versions deleted the, there are no more dependent children of the main offline edit version and that version can and should be removed in ArcGIS Pro only, don't delete it from the DB back-end!
I'd say this situation comes up for me about 80% of the time. So I will continue to test this out. 20% of the time when I remove an Offline Area after offline work is complete and the rec/post have been performed, I am able to delete the main offline edit version in ArcGIS Pro as expected without this back-end work.
At this point I am wondering if there is an issue where Field Maps isn't connected to our Enterprise Portal prior to removing the offline areas. If the credentials are somehow "stale" or if the iPad isn't fully connected to the network and signed in to Portal.
The sync version should be automatically deleted when the mobile user uses Field Maps to remove the offline area from their device, assuming the mobile device is connected to a network when the remove area option is invoked.
@Sean_Haile I have tried this again with another account and another iPad and I get the same result. I agree that what you said is what is supposed to happen. Remove the offline area, rec & post in the office to DEFAULT, and then be able to remove the version, but I keep getting the error. I updated Field Maps to the latest version on my iPad and get the same results. I think i was followed the guidance on this post. Guess I will try recreating the service and see if that does it.
@Sean_Haile I re-read your comment, I do not believe that the sync version would be deleted when the offline area is removed. Deleting the version is done by the manager or user after confirming that any edits are sync'd rec/posted, and the offline area is removed.
It seems that the issue comes up if I try to delete the version and there is still an offline area. This throws the error as noted, but can no longer be fixed in ArcGIS Pro regardless of what is done in Field Maps (e.g., removing the offline area, adding a new one, removing, etc.,). Trying to delete the version when there is still an offline area out there (for example, forgetting about that offline area, forgetting about a device) seems to orphan a replica that can no longer be removed unless I go into the SDE_Version table in the DB backend and remove the versions.
Thanks @DougBrowning . this is my suspicion as well. Even though I am pretty sure our users are on wifi on the iPad device when they remove offline areas, I wonder if the Field Maps connection to our enterprise Portal is stale, even though it technically thinks it still logged in, or something buggy there.
I am going to test by having the users log out and log back in to the Enterprise Portal in Field Maps prior to removing offline areas to see if that avoids the issue. Unfortunately though, once it happens one time, the orphans are stuck in the SDE versions table and need to be removed manually.
The goal of the VersionManagementService is to fully leverage versioning capabilities.
It allows users to manage and control different versions of their geospatial data, ensuring data integrity and synchronization across the geodatabase.This feature is particularly useful in collaborative environments where multiple users need to work on the same dataset without conflicts.It provides tools for creating, editing, and reconciling versions, as well as undoing and redoing edits, reconciling conflicts, and applying changes to the default version. The Version Management Component offers another way to handle versioning using a UI.
Listing versions is important in order to know the available versions in a version management service. These versions can then be used to perform edits or reconcile/post.The getVersionInfos is used to list versions.The method expects ownerFilter and includeHidden parameters. This method is querying a version based on owner name, and if the query is blankall versions will be returned.The following demonstrates a code example on how to list versions using getVersionInfos.
Calling getVersionInfos will only return basic information on each version. In order to get extended information about a version,such as current server locks or conflicts then the getVersionInfosExtended method should be used.The following demonstrates a code example on how to get information on a version using getVersionInfosExtended.
These methods return versionInfoExtended and a versionInfo object. The versionInfos object contains basic information about a version and the versionInfoExtended contains more detailed information about a version.Finding the default version information is simple, using the defaultVersionIdentifier property on the VersionManagementService class will return that information.The following demonstrates a code example on how to get the defaultVersionIdentifier.
795a8134c1