The changes on the �??default version�?� are not reflect on the corresponding table on th

[JamalNUMAN]

The changes on the �??default version�?� are not reflected on the corresponding table on the sql server,

I�??m wondering why the changes on the default version are not reflected on its corresponding table in the sql server.

Preliminary, I got the situation below (the default version and sql tables are identical)

[ATTACH=CONFIG]20288[/ATTACH]

The tree of the versions is as follow:

[ATTACH=CONFIG]20289[/ATTACH]

After editing the different versions and reconcile/post with the default version, I got

[ATTACH=CONFIG]20290[/ATTACH]

The changes are not reflected! Then when the changes on the default versions are reflected on the sql tables?


Thank you

Best,

Jamal

[LeoDonahue]

Are you synchronizing your replicas?

[Anonymous User]

Original User: blin26

Hi Jamal,

This is a typical editing question in a versioned ArcSDE (without using move edits to base option) environment. The situation you have seen is as expected. When you have reconciled and posted edits to the default version, the changes will show up in ArcGIS Desktop but not in your SQL Server business table side. Only when you have run a FULL compress for the ArcSDE geodatabase, then you will see the changes from the SQL Server business table as well.

Here is a simple example explaining the versioning editing workflow.

1. You register a feature class as versioned, then that will create 2 new tables in database side, like A100 table and D100 table, the number 100 is the registration ID for that feature class, so A100 stands for Add table and D100 stands for Delete table.

2. When you edit the feature class in Default version from ArcMap, like Creating a new feature, then the feature will be added to the A100 table, but not to the business table.

3. So basically when you see edits from ArcMap for the Default version, you will see changes like following:
features from business table + (plus) features in A table reflect to the Default version - (minus) features in D table reflect to the Default version

4. But when you see records from database side directly, you will only see features from the business (base) table.

Please refer to the following web help document regarding how to achieve a FULL compress for your ArcSDE geodatabase.
http://resources.arcgis.com/en/help/main/10.1/index.html#/The_geodatabase_compress_operation/003n000...

Thanks,
Ben L.

[JamalNUMAN]

Hi Jamal,

This is a typical editing question in a versioned ArcSDE (without using move edits to base option) environment. The situation you have seen is as expected. When you have reconciled and posted edits to the default version, the changes will show up in ArcGIS Desktop but not in your SQL Server business table side. Only when you have run a FULL compress for the ArcSDE geodatabase, then you will see the changes from the SQL Server business table as well.

Here is a simple example explaining the versioning editing workflow.

1. You register a feature class as versioned, then that will create 2 new tables in database side, like A100 table and D100 table, the number 100 is the registration ID for that feature class, so A100 stands for Add table and D100 stands for Delete table.

2. When you edit the feature class in Default version from ArcMap, like Creating a new feature, then the feature will be added to the A100 table, but not to the business table.

3. So basically when you see edits from ArcMap for the Default version, you will see changes like following:
features from business table + (plus) features in A table reflect to the Default version - (minus) features in D table reflect to the Default version

4. But when you see records from database side directly, you will only see features from the business (base) table.

Please refer to the following web help document regarding how to achieve a FULL compress for your ArcSDE geodatabase.
http://resources.arcgis.com/en/help/main/10.1/index.html#/The_geodatabase_compress_operation/003n000...

Thanks,
Ben L.

Thank you for the very integrated and informative answer. This is quite helpful.


I�??ve applied the �??compress�?�, �??rebuild indexes�?� and �??analyse dataset�?�, nevertheless, still the changes on the ArcGIS side are not reflected on their corresponding tables on the SQL side. Please, have a look on the screenshots below:

[ATTACH=CONFIG]20293[/ATTACH], [ATTACH=CONFIG]20294[/ATTACH]

Just in case of �??rebuild indexes�?�, I got message in green (I�??m not sure if it is relevant):

[ATTACH=CONFIG]20295[/ATTACH]


What might further be required to get them identical (the data on the ArcGIS and SQL)?

Best

Jamal

[JamalNUMAN]

Hi Jamal,

This is a typical editing question in a versioned ArcSDE (without using move edits to base option) environment. The situation you have seen is as expected. When you have reconciled and posted edits to the default version, the changes will show up in ArcGIS Desktop but not in your SQL Server business table side. Only when you have run a FULL compress for the ArcSDE geodatabase, then you will see the changes from the SQL Server business table as well.

Here is a simple example explaining the versioning editing workflow.

1. You register a feature class as versioned, then that will create 2 new tables in database side, like A100 table and D100 table, the number 100 is the registration ID for that feature class, so A100 stands for Add table and D100 stands for Delete table.

2. When you edit the feature class in Default version from ArcMap, like Creating a new feature, then the feature will be added to the A100 table, but not to the business table.

3. So basically when you see edits from ArcMap for the Default version, you will see changes like following:
features from business table + (plus) features in A table reflect to the Default version - (minus) features in D table reflect to the Default version

4. But when you see records from database side directly, you will only see features from the business (base) table.

Please refer to the following web help document regarding how to achieve a FULL compress for your ArcSDE geodatabase.
http://resources.arcgis.com/en/help/main/10.1/index.html#/The_geodatabase_compress_operation/003n000...

Thanks,
Ben L.

An instructor provided me with a code (attached) that does the whole process

�?� �??analyse dataset�?�
�?� �??rebuild indexes�?�
�?� �??compress�?�

[ATTACH=CONFIG]20333[/ATTACH]

The first time I applied it worked fine and the data in the sqle side is updated according to the ArcGIS side. I did further edits in the default version and applied the script again. Unfortunately, the changes were not reflected on the sql data

[ATTACH=CONFIG]20334[/ATTACH]

What might be the issue behind?

Best

Jamal

[Anonymous User]

Original User: blin26

Hi Jamal,

First of all, analyse datasets and rebuild indexes will not contribute to the compress process, those however, will improve your overall database performance.

Secondly, only a FULL compress will push all the edits to the business (base) tables. In your Python script, the compress will only be treated as a partial compress, but not a full compress.

From the web help link I provided early, here is the detail information regarding FULL compress.

"Fully compressing a geodatabase
In a fully compressed geodatabase, there are no rows in the delta tables and the state tree is trimmed back to zero. Performance improvement is greatest if the geodatabase is fully compressed. To achieve this, do the following:

�?�Reconcile and post all outstanding changes in child versions to the DEFAULT version. As the geodatabase administrator, you can see in what order versions should be reconciled by default by opening the Reconcile Order subtab of the Versions tab on the Geodatabase Administration dialog box. See Version properties for information on the Reconcile Order subtab.
�?�Delete the versions themselves after you have reconciled and posted edits.
�?�Make sure no user is connected.
�?�Perform the compression operation."

You then can recreate the user versions after the full compress.

Thanks,
Ben L.

[JamalNUMAN]

Hi Jamal,

First of all, analyse datasets and rebuild indexes will not contribute to the compress process, those however, will improve your overall database performance.

Secondly, only a FULL compress will push all the edits to the business (base) tables. In your Python script, the compress will only be treated as a partial compress, but not a full compress.

From the web help link I provided early, here is the detail information regarding FULL compress.

"Fully compressing a geodatabase
In a fully compressed geodatabase, there are no rows in the delta tables and the state tree is trimmed back to zero. Performance improvement is greatest if the geodatabase is fully compressed. To achieve this, do the following:

�?�Reconcile and post all outstanding changes in child versions to the DEFAULT version. As the geodatabase administrator, you can see in what order versions should be reconciled by default by opening the Reconcile Order subtab of the Versions tab on the Geodatabase Administration dialog box. See Version properties for information on the Reconcile Order subtab.
�?�Delete the versions themselves after you have reconciled and posted edits.
�?�Make sure no user is connected.
�?�Perform the compression operation."

You then can recreate the user versions after the full compress.

Thanks,
Ben L.

Thank you Ben for the very useful answer. It works fine with me now


I couldn�??t understand how the �??system�?� could detect whether I did the reconcile/post between the versions or not! And thus in case I didn�??t, the edits in the ArcGIS side data are not reflected on the SQL side data!

Best

Jamal

[JamalNUMAN]

But what are the pros and cons for versioned feature classes with and without “move edits to base” option?

Is it accurate to say:

• Versioned feature classes with “move edits to base” option are more performant but have less functionalities (for example, archiving is not possible here)
• Versioned feature classes without “move edits to base” option are less performant but have better functionalities (for example, archiving is possible here)

[JamalNUMAN]

Is it accurate to say:

• Versioned feature classes with “move edits to base” option are more performant but have less functionalities (for example, archiving is not possible here)
• Versioned feature classes without “move edits to base” option are less performant but have better functionalities (for example, archiving is possible here)