ArcGIS Enterprise 11.0\Pro 3.0.2: Why edits applied on source data of “feature layer” are not reflected on the service and vice-versa?
Despite the many advantages of the “feature layer” service as it behaves exactly as if it’s a feature class and thus symbology, labeling, analysis, export, etc can be performed, it has a major disadvantage when it comes to editing due to the fact that edits applied on source data of “feature layer” are not reflected on the service and vice-versa
Your original data is in a file geodatabase (D:\jifna.gdb-parcels). When you publish that to a Hosted Feature Service there are several things that happen. Just like in ArcGIS Online the publishing process creates a featureclass in the Relational Data Store (a PostgreSQL database). A Hosted Feature Service is created and registered with the Enterprise Portal, and then the data is copied from your file geodatabase and appended to the newly created and empty featureclass in the database. At the point of publishing, you take a snapshot of the file geodatabase data and they become separate entities. You can update either, but they are not connected.
Another way to think of this is that if someone gave you a shapefile, and you copied it to a file geodatabase, then they are now disconnected. No amount of editing in the shapefile will ever update the file geodatabase unless you intervene.
It's also important to remember that if your source data is in a file geodatabase then it is not editable via any ArcGIS Server process. File geodatabase are 'single-user' editable. To edit via a web service (multiple users) you must use a datastore or Enterprise geodatabase (or a query layers onto a spatial table in a non-geodatabase).
A "hosted" feature layer is disconnected from it's source, even if the source came from an enterprise geodatabase. Regardless whether it is AGO or AGE, the behaviour is the same and is intentional. If you need edits to be in-sync, then use referenced data as your share methodology. This way, edits at source, or edits via web client will be reflected.
As per the screenshot below, it appears that there is kind of connection that's kept between the “hosted feature layer” and its source data. For example, if a field is required to be added to one of the class features of the source data that particiaptes in the service, then schema lock error pops up.
What I meant here that we need the users of our services to enjoy the advantages of publishing our data with “feature layer” format but unfortunately, we are losing one major functionality: edits are not synchronized! This means that we need to publish the same data twice: one as “map image” (feature enabled, of course the data needs to be enterprise), and the second as “feature layer”
You can take advantage of synchronized edits if you use a traditional feature service. A hosted feature service will never be synchronized with your local copy of data because you are physically copying the data to the server.
Again, do not use a hosted feature service. Use a traditional feature service with a DB that is registered with the ArcGIS Server pulling from an enterprise geodatabase. If you do it that way, your edits will be synchronized.
The schema error you are receiving doesn't have anything to do with the hosted feature service. You or someone else must be locking you out. You have to close all connections in order to add a field.
I feel that the “feature layer” service is behaving as referenced and copied at the same time! But it’s neither referenced nor physically copied!
It is copied, but at that point in time and once only. It's like I said the other day, if you are given a shapefile and copy it to a file geodatabase, the two do not stay sync'd. if you edit the shapefile it does not flow to the fGDB. If you edit the fGDB it will not go to the shapefile. By using a hosted feature services you have created a new instance of that data, as a snapshot, and it is disconnected from the original source.
As someone from Esri told you, if you need a feature service and must update the source data, then you need to use an Enterprise Geodatabase, create a referenced Map Service and then enable Feature Access to create a 'traditionall' feature service.