A tool to transfer the Add\Delete tables to the business table,

[JamalNUMAN]

(again): A tool to transfer the Add\Delete tables to the business table,


I???m wondering if there is simple tool that can transfer the Add\Delete tables to the business table. I got the attached model tool but it appears not to do the job

[ATTACH=CONFIG]31580[/ATTACH], [ATTACH=CONFIG]31581[/ATTACH]


What other tools might transfer the Add\Delete tables to the business table

Thank you

Best

Jamal

[Anonymous User]

Original User: mboeringa2010

Jamal,

What do you mean with "attached model"? I only see a table... you probably mean you have made some edits in a replica or version, and now wish to transfer these to your main geodatabase and add them to DEFAULT and possibly compress to state 0?

Other than using the ESRI supplied tools (synchronize replicas, reconciling & posting version changes, and compress your geodatabase), it is unwise to start messing with the tables in SQL Server Management Studio. You may wreck your geodatabase.

If you need to see the state of DEFAULT, including all the Adds and Deletes in an application other than ArcGIS / non-ESRI software (e.g. in SQL Server Managament Studio), you can connect to the Versioned View instead of the base table. It should show you the latest state of DEFAULT including all changes in the Adds and Deletes tables (at least as far as reconciled and posted to DEFAULT, if you don't reconcile and post to DEFAULT, the changes of course won't be visible in DEFAULT).

[Anonymous User]

Original User: Jamal432@gmail.com

Jamal,

What do you mean with "attached model"? I only see a table... you probably mean you have made some edits in a replica or version, and now wish to transfer these to your main geodatabase and add them to DEFAULT and possibly compress to state 0?

Other than using the ESRI supplied tools (synchronize replicas, reconciling & posting version changes, and compress your geodatabase), it is unwise to start messing with the tables in SQL Server Management Studio. You may wreck your geodatabase.

If you need to see the state of DEFAULT, including all the Adds and Deletes in an application other than ArcGIS / non-ESRI software (e.g. in SQL Server Managament Studio), you can connect to the Versioned View instead of the base table. It should show you the latest state of DEFAULT including all changes in the Adds and Deletes tables (at least as far as reconciled and posted to DEFAULT, if you don't reconcile and post to DEFAULT, the changes of course won't be visible in DEFAULT).

Sorry Marco for the confusion.

1. The model I used is now attached

2. My enterprise geodatabase has no versions. It is edited on the default. Then there is no need to reconcile and post or synchronize

[ATTACH=CONFIG]31583[/ATTACH]

3. I have just visited the enterprise geodatabase via SQL to have a look but not to play with it. I found out that the Add\Delete tables are not transferred to the business tables even after applying the �??compress database�?� tool.

[ATTACH=CONFIG]31584[/ATTACH]

What might be the issue? Which tool is supposed to be used to get the data updated in the business table?

[WilliamCraft]

The "Is Replica" flag is set to True in your most recent set of screenshots.  Is the dbo.DEFAULT version of the Communities_Points database set up for two-way replication or one-way replication where it is the child? 

What is listed when you run the following query against your databases?

select * from Communities_Points.DBO.versions

I'm particularly looking to know if there are any SYNC_SEND_XXX versions which have not been synchronized.  You may want to query the GDB_REPLICALOG table as well to see if there are any errors reported in synchronization.

[Anonymous User]

Original User: mboeringa2010

What might be the issue? Which tool is supposed to be used to get the data updated in the business table?

Jamal,

Just a quick observation, but based on your first screenshot in the last post, it shows the dataset being a "replica" ("Is Replica" is TRUE).

Are you actually looking in the right database, and compressing the right one? Shouldn't you be synchronizing with the parent and compress there?

Other thing: did you actually select "Reconcile and Post with parent version" in the Synchronize Changes wizard? If not, the data will not have been automatically reconciled and posted to your DEFAULT, and you will have to manually reconcile and post the replica version against DEFAULT and subsequently compress.

Please also note that even if you don't create additional versions, replication still requires the parent database to be versioned, and a Replica Version will be created upon creating the replica. This is why you need to reconcile and post this replica in the parent database against DEFAULT, and compress, before the edits will show up in the base table.

[JamalNUMAN]

Jamal,

Just a quick observation, but based on your first screenshot in the last post, it shows the dataset being a "replica" ("Is Replica" is TRUE).

Are you actually looking in the right database, and compressing the right one? Shouldn't you be synchronizing with the parent and compress there?

Other thing: did you actually select "Reconcile and Post with parent version" in the Synchronize Changes wizard? If not, the data will not have been automatically reconciled and posted to your DEFAULT, and you will have to manually reconcile and post the replica version against DEFAULT and subsequently compress.

Please also note that even if you don't create additional versions, replication still requires the parent database to be versioned, and a Replica Version will be created upon creating the replica. This is why you need to reconcile and post this replica in the parent database against DEFAULT, and compress, before the edits will show up in the base table.

Thank you very much William and Marco for the help,

All what I wanted is to have tools that can transfer the updates stored on the Add\Delete tables to the physical (business).

[ATTACH=CONFIG]32046[/ATTACH]

Do the tools depicted in the screenshot below can transfer the values stored in the Add\Delete tables to the business table?
[ATTACH=CONFIG]32048[/ATTACH]

[TimothyHales]

[Anonymous User]

Original User: crafty762

Do the tools depicted in the screenshot below can transfer the values stored in the Add\Delete tables to the business table?

The Compress GP tool you show in your model is responsible for moving rows from the A and D tables into the base table, assuming that no child versions reference the state IDs of those particular rows.  Reconciling and posting beforehand (which you've correctly delineated in your model) is what moves your state ID pointers in the geodatabase.  That is why reconciling, posting, and compressing are such critical parts of the geodatabase maintenance process.

[JamalNUMAN]

The Compress GP tool you show in your model is responsible for moving rows from the A and D tables into the base table, assuming that no child versions reference the state IDs of those particular rows.  Reconciling and posting beforehand (which you've correctly delineated in your model) is what moves your state ID pointers in the geodatabase.  That is why reconciling, posting, and compressing are such critical parts of the geodatabase maintenance process.

Thanks William.

Sure, the �??reconcile versions�?� does transfer the updates from the parent to child and from child to parent (if the �??post versions after reconcile�?� is checked).

[ATTACH=CONFIG]32052[/ATTACH]

Now, being the updates are reflected in the sde.default and its versions by the �??reconcile version�?� tool, the �??communities�?� in the SQL server doesn�??t match the one on the ArcGIS

Number of records of the �??communities�?� in the SQL is 781
Number of records of the �??communities�?� in the ArcGIS is 788

[ATTACH=CONFIG]32051[/ATTACH]

Which tools can be used to have Number of records of the �??communities�?� in the SQL and in ArcGIS equal?

[Anonymous User]

Original User: crafty762

Please post the results from the following query against your geodatabase:

select * from Communities_Points.DBO.versions

If everything has been reconciled and posted, then compressed, I agree that the base table should match what's in SDE.DEFAULT (or the versioned view of the SDE.DEFAULT as Marco mentions above) in terms of record count.  It feels like something else is locking a particular state and preventing its edits from being moved from the delta tables to base.