Latest Contributions by JessicaParteno

What if have a web service which supports creating a new version?  Let's say that I want users in the field to submit potential changes which have to be reviewed/moderated.  In this case, each user would have their own SDE version. Hi, Feature services were designed to support one version per service. This workflow allows the author of the service to control which version is exposed through the feature service. If you want to publish multiple versions of the same data, a separate feature service will have to be created for each version. The ability to create new versions through the feature service is not currently supported. The advantage to this workflow is that it prevents end users from selecting the wrong version  and it also prevents the end users from creating hundreds of versions that can be very difficult to manage. If you are using versioned data in your feature service you can use QA QC and then reconcile and post the selected edits from the version publish in the feature service to control which edits are maintained in the Geodatabase. Hope this helps, Jessie ... View more

  If I have a GDB that is versioned, I would also, like to store date that can be edited via non versioned in the same database that may be setup via a relationship class with the versioned  layer(s), maybe I am missing something, but I have always had issues when blending these two ways for editing data in the same database. Hi Ted, Having versioned and non-versioned data in the same Geodatabase is supported and it is also supported in feature services. When you have a feature service with versioned and non-versioned data, both type of layers can be queried and edited through the service. The main difference will be in the QA QC of the edits in the Geodatabase. As far as using a relationship class to related versioned and non-versioned data, this can be done in the Geodatabase but only with Simple relationship classes because Composite relationship classes propagate the version type to both the origin and destination objects. If you want to use a relationship class between versioned and non-versioned data it is important to note that both the origin and destination in the relationship class have to be registered with the geodatabase. It is also important to note that if the destination in the relationship class is not versioned, when features are deleted in the origin the foreign key values will be set to Null in the destination. During the reconciling and posting of the versioned feature class if you decide to restore the deleted features, the foreign keys will not be set back to the original foreign key value, this will have to be done manually. Hope this helps, Jessie ... View more