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

7724
21
Jump to solution
02-19-2014 07:32 AM
JamalNUMAN
Legendary Contributor

(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

----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
1 Solution

Accepted Solutions
by Anonymous User
Not applicable
Original User: asrujit

From the screen shots I can see that you are running the Model from the ArcMap interface.

1) Did you save the edits and stop editing?
2) Try to close the ArcMap after editing and then run the Model from ArcCatalog. Does this help?

You must understand that just running the compress will not push all records from the delta tables to the Base table. There should be no one editing the data, when you are attempting the compress if you want a "full compress".

View solution in original post

21 Replies
by Anonymous User
Not applicable
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).
by Anonymous User
Not applicable
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?
0 Kudos
WilliamCraft
MVP Regular Contributor
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.
by Anonymous User
Not applicable
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
Legendary Contributor
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]
----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
TimothyHales
Esri Notable Contributor

Clip_106.jpg

by Anonymous User
Not applicable
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
Legendary Contributor
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?
----------------------------------------
Jamal Numan
Geomolg Geoportal for Spatial Information
Ramallah, West Bank, Palestine
0 Kudos
by Anonymous User
Not applicable
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.
0 Kudos