Select to view content in your preferred language

Locking parcel has changed in default

1443
9
01-20-2011 07:10 AM
davidvan_pelt
Regular Contributor
Help - how do I get rid of this error. I'm editing in default so there IS nothing to reconcile. We also run a script that does a compress every night... is this a bug? Does the error refer to orphaned locks? How can I get the error to go away?

Please see screen shot for full text of error.

Thanks
Tags (2)
0 Kudos
9 Replies
CarlosIsaac_Cabrera
Deactivated User
Help - how do I get rid of this error. I'm editing in default so there IS nothing to reconcile. We also run a script that does a compress every night... is this a bug? Does the error refer to orphaned locks? How can I get the error to go away?

Please see screen shot for full text of error.

Thanks


Do you have any other versions?  I'd check each version of default.  You may have edited in one of those and not known it.
0 Kudos
ChristineLeslie
Esri Contributor
David - try commiting the job that was edited to release the locks - The job needs to be committed even on default. The Commit Job command needs to be added from the Customize menu.

And yes, we need to get that command back on the job context menu, it should not be hidden in Customize.

Christine
0 Kudos
NickKenczka
Emerging Contributor
David - try commiting the job that was edited to release the locks - The job needs to be committed even on default. The Commit Job command needs to be added from the Customize menu.

And yes, we need to get that command back on the job context menu, it should not be hidden in Customize.

Christine


Hey Christine,

Do you have to "Commit" each job even if you are in automatic mode?  Our organization has just made the leap to the SDE environment and I am testing our fabric in both the default version and the level below.  I'm finding that in default, I can proceed as normal and there are no locking issues.  However, in the version just below default every single parcel is locked and I cannot quite understand why.  This is my first time working in SDE so I'm really hoping its just my lack of understanding of the fabric in SDE.  Any ideas?
0 Kudos
ChristineLeslie
Esri Contributor
Hi Nick

Strange that every single parcel is locked? Only the ones that have been  edited in default will be locked. And yes, you will have to commit the jobs on default and then reconcile so that the parcels on the version become unlocked.

let me know if you have any issues

Christine

Parcel Editor team
0 Kudos
TiffanyPuett
Frequent Contributor
Nick,

Are you getting the same error message as the first post?  How did you migrate/load your parcel fabric to SDE?  Was there a topology invloved?  If so, is there a chance that it was validated on the default after you created the version below?  That may cause a lock on all of the parcels.

Since your testing, you may try dropping the verison and then recreating it from a "clean" default version.
0 Kudos
NickKenczka
Emerging Contributor
Nick,

Are you getting the same error message as the first post?  How did you migrate/load your parcel fabric to SDE?  Was there a topology invloved?  If so, is there a chance that it was validated on the default after you created the version below?  That may cause a lock on all of the parcels.

Since your testing, you may try dropping the verison and then recreating it from a "clean" default version.


Hello Tiffany,

No, I am not getting the same error anymore.  It was actually just a one time thing.  What I had to do was actually 'commit' each job (at default I believe) that was outstanding in order to unlock the parcels in that version.  We loaded our fabric into SDE from a exported Cadastral XML file containing the data.  So we are good to go now, things are working very smoothely.  I'm assuming you are working with a fabric?  If so, how long has it been now?  What are you finding in terms of any wierd/inconsistent things happening?
0 Kudos
TiffanyPuett
Frequent Contributor
Nick, that's a good question!  Perhaps we should start another post!  Just to name a few, I saw the one about the "breakline" tool not being enabled when it should.  I can't replicate it but I've seen it.  Another thing that seems to be inconsistent is "Load traverse file" tool from the Parcel Utilities Add-In.  It works a few times and then it crashes ArcMap every time and I have to reboot my machine.  I would be hard pressed to guess it's the computer.  It's brand new and has never had any ArcGIS products installed on it.

I've been working on the fabric not long after it's release.  We've still got some testing to go before we implement.  I'm currently waiting for some service packs or a new release to "stabilize" it.  It looks like you've gotten your feet wet a bit.  I'm interested in hearing your thoughts.

PS I went ahead and created a new post:  http://forums.arcgis.com/threads/27224-Inconsistencies-Odd-behavior-in-the-parcel-fabric?p=90255#pos...
0 Kudos
NickKenczka
Emerging Contributor
This issue keeps rearing is ugly head for me time and time again. This really makes no sense. Our fabric is in SDE but is not versioned and I am the only one editing it right in default. I 'commit' all my jobs in default, then unjoin a certain group of parcels and there you go, here is this error message. This really makes no sense. I cannot reconcile with default, obviously, because it is not versioned. Has there been a resolution to this yet?
0 Kudos
TimJacobsen
Occasional Contributor
We were running into the same error and the problem has subsided after we made two changes.  We are an SDE in an oracle database.  I'm not a DB guy but my understanding was that traffic for the DB was running thru 2 nodes.  When the load balancer shifted traffic from one node to another all of our edits were getting dropped and we getting that error message.  We shifted our traffic to go to only one node, and that was the first change we made.  The second was while every user had insert, delete and create priviledges on the feature class, there was still a group setting that user needed to have  insert, delete and create priviledges on.  Since we made these changes a few weeks ago the problem has not reared it ugly head since.  Fingers are still crossed though, good luck!
0 Kudos