Versioned Views or Compress for Branch Versioning

[KimGarbade]

I'm almost afraid to ask but here goes...

We are transitioning a long standing data entry/editing process to a new Branch Versioned database. 

Using our legacy (traditionally versioned) database we ran processes against the versioned views. This method helped us ensure we were only running a third party application update on current records (those not in a non-posted version).

But when I look at the Branch Versioned database tables in SQL Server I get worried.  I see no versioned views and the "Base" tables contain records for all records ever created, edited, or even deleted in the feature class, even features in versions that were deleted and/or not yet rec and posted.  I also don't see how to tell which records should exist (I.E. have not been deleted or never posted) from the records that should exist.

If I go into ArcGIS Pro and open the table it looks right, but it is sure a mess in SQL and that is were our third party update process lives.

Is there a way to filter a Branch Versioned Feature Table in SQL Server to see what a "Versioned View" would show.  Or at least to tell which records in the Branch Versioned Feature Table in SQL  are the currently existing features (I.E. have not been delete, or which are the most recent edits, etc).  

Is the only option to export the tables out of Pro into new tables in a different database?

P.S. another issue is that we have some feature classes with 100,000 + features in them, if every deleted and edited and non-posted record gets written to the table, that will be thousands of extraneous features a year. 

Can I not get rid of deleted features or unreferenced features from deleted versions/database states? I must be misunderstanding something.  Please set me straight.

Thank you for your time.

[KimGarbade]

I think after some research, and I could be wrong here, so if I am please post a correction (I don't want to spread false info), the answers are:

1) Versioned views don't exist when you use branched versioning.

2) You cannot use a database (SQL) query to just pull the records you want out of the base tables directly in your DBMS (SQL Server in our case).  You have to direct your queries through the service (REST API).

3) The answer to the P.S. I'm a little more unsure of, but I think those records just stay in the base table, since it is assumed your never going to use it directly anymore (only access is through the service).  Maybe it is assumed the extra records its carrying around aren't a big deal... maybe you have to run some special API Service based Compress I haven't learned yet (now that I have to learn the REST API)...If anyone know the answer to this one I would still appreciate the info.  Thanks.

[DanMoore · Accepted solution]

With branch versioned data, there is no need to compress. You are correct in stating the records are in the base table. There are other people that have been curious about pruning records, and that is an idea that is still open.

https://community.esri.com/t5/geodatabase-questions/how-can-i-prune-a-branch-versioned-featureclass/...