Is RegisterGeodatabaseAsync supported when the REST Endpoint backs onto versioned data?
The reason I ask is that after generating a SQLite geodatabase on one device, transferring it to another device and calling RegisterGeodatabaseAsync I get the following error:
Message: "Error code '500' : 'Unable to complete operation.'\r\nFailed to register replica on the server."
I looked at the logs on the server and the following error message exists:
Error: An error occurred while adding an entry to the FEATUREDATASET_CLASSES or the FEATURECLASSES table. [Read only data or unversioned data cannot be replicated. Data versioned with the option to move edits to base cannot be replicated. GlobalIDs are required for two way and one way replica data. Creating one way replica using archiving requires archiving the replicated parent data.]. Version not found [GIS.Ags_Fs_1416518016983_7280]. Version not found [GIS.Ags_Fs_1416518016983_7280]. Version not found [GIS.Ags_Fs_1416518016983_7280]. Version not found [GIS.Ags_Fs_1416518016983_7280]. Version not found [GIS.Ags_Fs_1416518016983_7280]. Version not found [GIS.Ags_Fs_1416518016983_7280].
Looking at the GDB_ITEMS table in ArcSDE there is a record named 1416518016983 which has a unique ID of 7280:
If I look in the sde_versions table I can see a placeholder for that version:
It does not look like the same version name but I've had that before in error messages when using the ArcObjects APIs.
I know the 2nd half of this is in the server/replication teams domain but any suggestions would be great!
Could you have a look for this document to ensure that you have all steps done to prepare the data for offline usage.
For a detailed walk-through of this scenario, see Tutorial: Setting up feature service data for offline use.
You can publish nonversioned data from a 10.2 or later release enterprise geodatabase, take the data offline for editing, and synchronize changes with the enterprise geodatabase.
If clients will only query the data they download, the data in the feature service can be either nonversioned or versioned. If the data is nonversioned, prepare it as described above. If the data is versioned, configure it as follows:
- Include Global IDs on the datasets.
- Register the datasets as versioned.
- Relationship classes and attachments must use a Global ID primary key. For more information, see the Attachments and relationship classes section of this topic.
You can publish versioned data from any supported version of the enterprise geodatabase and take the data offline.
Had to move onto a different task but I am pretty sure that I checked that stuff.
I did get it working with a simple feature class but not with the data we wish to use.
I still have the VM with where I can repo the issue, is there some additional logging I can turn on?
We have exactly the same problem. We publish data from a 10.0 geodatabase in Oracle. So i just want to know the version of your geodatabase and eventually if you solved this problem :)
Might be late but have you checked that your Oracle Schema from which you published the service had writing rights in the DB ? Otherwise replica does not work even if clients will only query the data. I had the same error message and after ressourcing with another schema that had writing rights, it worked.
From what I can tell RegisterGeodatabaseAsync does not work with a replica created from a versioned database. What I came up with that seems to give the same results as far as sharing a database.
The replica that is created using this approach can be shared to other machines and when you sync it will sync against the version that was created when the replica was generated. When you Sync data just be sure that you connect to server as this generic user
Unfortunately, this still requires you to create a version for each offline geodatabase. Which I find difficult from an implementation perspective because on the enterprise I need to be posting and reconciling multiple versions to manage a offline system if I want to use .geodatabase files of reasonable size
antti kajanus something to consider for future runtime versions would be the ability to explicitly define what version to use to generate a replica. This would simplify deployment and the management process on the enterprise side.