We are exploring the viability of using branch versioning. Our organization utilizes SQL views for much of what we serve out to our portal as enrichment services. Looking over the structure of how the branch versioned tables are built, it appears we won't be able to call just a generic select statement to pull data from the base table, but will have to incorporate some heftier sql just to get the correct rows to return. Is this something that has been addressed and I've just missed it? Or does ESRI have a sample of the code needed to pull the current state of features in the default version?
We'd love to explore branch versioning, but if it removes support for database views (or over complicates them), it would be a real buzzkill.
Branch versioning follows a services based implementation pattern and there are not currently any plans for direct SQL access. As you may have noticed, versioned views are not created for branch versioned datasets. REST calls can be used for these workflows to query and edit within specific branch versions. Have you attempted to query within REST using the Query (Feature Service/Layer) operation?
Thank you for the reply Melissa.
What we do for some of our services is create a view pulling data from multiple databases/tables etc.. register it with our sde database and then publish that out as a service. For example: we have street gis features. In our asset management software we have records of work performed, inspections, etc... instead of requiring people to perform processing or maintain joins, we create views. In that example it may be how many times have we fixed potholes on a street segment in the last 2 years and when did we last do it. With a view, this is always accurate to the data in both systems and available to everyone in our city via our internal portal.
I hope that makes sense.