3

I’m trying to set up a python script so that I can schedule our rec/post to run on a server. I’ve created a model with the Reconcile Version tool, with the option to Post checked on. I then export this to a Python script. I run the script, and it finishes without any errors, but I do not see that my edits are posted to the default version. Is it not possible to script this tool, or is there a switch that I’m missing?

I’m using ArcSDE 9.3.1.

1
  • What about exporting out the pre-edited records frpm the parent before rec/post-ing? I would like to do this so I can surface these history records in a web app keeping them in a database.
    – Justin
    Mar 28, 2011 at 16:42

2 Answers 2

3

You should be able too. Below is the help for the tool, and how I've implemented it before:

http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?id=1991&pid=1986&topicname=Reconcile_Version_(Data_Management)

is ESRI's help for the gp tool for that functionality. Try:

gp.reconcileversion_management(inworkspace, versionname, "DEFAULT", "BY_OBJECT", "FAVOR_TARGET_VERSION", "NO_LOCK_ACQUIRED", "ABORT_CONFLICTS", "POST")

is the way I've used it. However I've had issues running python on our server so I ported the process over to a full arcobjects desktop app that seems to run fairly well.

3
  • Have you run the script successfully outside of an edit session?
    – Zachary
    Mar 9, 2011 at 19:35
  • yup. It's one of our fall backs for debugging purposes if our batch/automatated reconcile/post process fails.
    – Luke
    Mar 9, 2011 at 19:48
  • @Zachary: i think it typical to use that outside of edit session. Same as @Luke, the above statement in a try/except with various logging and notification when the rec/post fails. Mar 10, 2011 at 1:26
1

Luke's answer of using the GP function should work. You should be able to rec/post the changes with that GP tool. However, I bet that the reason that you are not seeing the changes is that whatever client you are using to see those changes (ArcGIS Server, ArcMap, your own custom tool, whatever) has not called IVersion2::Refresh and thus is still pointing to the previous database state. You can force a call by using that interface or closing and opening the workspace. The changes should then be visible.

You have to remember that database version changes still use a polling (vs pushing) mechanism, so if, for example, the underlying database state changed and you try to edit it without calling refresh, you may encounter an error (that is unless the underlying Workspace::StartEditing code has been updated to force a refresh in its internal implementation) because the client still thinks that the version is pointed to an old state id.

To better understand the relationship between Versions and State IDs, I recommend you read this document. It may be long, but it will be worth it in the long run!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.