Versions, Deletions & Parcel Locks....oh my!

[BettyConces]

We have been working in the parcel fabric for a couple years now. We use versioning and have 6 editors doing parcel maintenance. I am one of the 6 but I also check the fabric for things like missing start/end dates, construction polys left in the fabric...things like that.

Lately, even after a version has been posted and deleted, when there are polys that need to be deleted and I attempt to do so I get an error stating the parcel is locked but it doesn't happen to all polys. I have been able to delete some. These versions have been posted & deleted at least a week if not a month ago. Right now I have about at least 60 polys that need to be deleted. To keep them out of the active parcel fabric I can make them historic. I can also edit their attributes, but I cannot re-join them nor can I delete them.

Does anyone know why that would be? I understood that once a version is posted those parcel locks are supposed to disappear. (Still true if the version has not been deleted right away?)

Also I believe that some of the editors post their version, hang on to it and delete it a couple days later. Could there be some sort of interference with posting a version but keeping it around in the version manager for a couple days longer?

I know one editor, when she couldn't delete her parcels, created a new version with the original version name, reconciled and posted then deleted that version and started a new one but was still unable to delete her parcel(s) - now part of the 60.

I'm stumped! I hope someone has a clue for me that I can chase to figure out why this is happening.

[anna_garrett]

Total shot in the dark, but have you done the compress/rebuild index/analyze dataset that's recommended for versioned databases? I *think* I've run into this before but I can't exactly recall. I didn't make a note beforehand, but if I have some funky problems like that I'll just reconcile all versions (there's only 2 of us here, not sure if this would be feasible for you), delete them, unregister the GDB and run the recommended maintenance routine a few times then try and get the problem to repeat itself. 

Here's a link to what I'm talking about: Recommended version administration workflow—ArcGIS Help | ArcGIS Desktop 

[BettyConces]

Thanks Anna. Are you working in a parcel fabric? I was thinking the parcel fabric was different a different animal than a geodatabase. We used a GDB prior to parcel fabric and we did have to compress/rebuild/etc regularly even though it wasn't versioned.

I will definitely check into that though. It did cross my mind that some sort of 'clean up' needed to happen. This is all happening now that ALL of our parcels are in PF and all of the mappers are working in it although I don't know if it's related.

Thanks again, I appreciate the reply!

[anna_garrett]

Yeah, we work in a parcel fabric. The parcel fabric resides in a GDB, think of a GDB like a folder and all your parcels and such reside in it. Do you have someone that maintains all that on a server for you guys?

[anna_garrett]

Oh and before I forget - sometimes the job book can cause problems if it still has a ton of jobs in it that are just hanging out there. I do not recall exactly why they persist in the book after post/reconcile, but every once in a while I do have to go in and manually delete jobs that have already been completed. 

[BettyConces]

Thanks again Anna! Good to know, I hadn’t thought of looking in the job book

[DianeBaker]

Was this ever solved?  I'm experiencing this problem as well.  We did a compress and rebuildign the indexes.  We have zero versions existing right now.  Not sure what else to try at this point.

[BettyConces]

What happened w/us is that we were using a custom maptile checkout program that wasn't clearing out the version locks after the version was posted & deleted. What we ended up doing was, in an edit session, select the parcel with the lock and attempt to open it. For us, this would generate an error message about the poly being locked and it would reference the version name that locked the parcel. The owner of the version would then need to create another version with the exact same name, make it active, start editing, reconcile & post, stop editing then delete the version. This removed the parcel lock and we could go forward. I hope this helps! ~b

[TinaMorgan1]

If I understand correctly, you see an error when you attempt to edit polygon records from your feature class.  Could you include the exact error you see when attempting to delete the records?

[JohnFell]

On occasion parcels become locked or inaccessible due to many possible factors. There are a number of possible states that a parcel may be in and what has occurred for the feature to be locked for editing. 

If an editor finds that parcels are in a locked state and cannot be edited after the user having them locked has reconciled and posted then there is an active job in the job book that must be committed. Once the job is committed, the parcel should be available for deletion.

1. In ArcMap go to Customize and in the commands tab type in "commit." The Commit Job command button will become available. Add this to any ArcMap toolbar. 
2. Navigate to the Catalog window and connect to the geodatabase containing the parcel fabric using and ADM connection.

3. Drag and drop the parcel fabric into the ArcMap display area and start editing.

4. From the Parcel Editor menu click on Job Book.

5. Look for any jobs in the job book that are Active.

6. Select any jobs with an Active status in the job book grid and click the Commit Job button recently added to the Parcel Editor toolbar. The job status will change from Active to Committed.
7. Reconcile and post, stop editing, and save edits. Close ArcMap when finished.
8. This process should place the parcels in an unlocked state. Verify this by opening ArcMap and connecting to the version that identified the locked parcels originally. Verify that the user previously denied edit permission is now able to make the necessary edits.