Hi Rachel,
This Ana Young from DOTD in Louisiana. You helped us with a ticket regarding an error message that was being generated by our out-of-whack centerline sequence table i.e "No centerline found at m value..." (or something like that). I apologize for taking so long to reply but thanks for getting back to me on this issue.
I was told having locks is not such a big problem if no schema changes are being made but it still bugs me. So, my maintenance procedure is to reconcile and post the versions up through Default, then to reconcile everything to Default (without posting), then to compress the database, then to rebuild the indexes, and finally to analyze the dataset. I do this once a week and generally on Fridays.
I've run into the problem where locks aren't released even after posting and the person who created them is unavailable to release them or for some reason the locks can't be released and I have to turn off conflict prevention and immediately turn it back on to get the locks to release (the allow lock transfer checkbox is enabled but doesn't appear to work). The root lock is associated with our lowest main version, QA_Edit (we have three i.e. QA_Edit, Edit_Default, and Default). And folks have been instructed to post up to QA_Edit from their jobs before maintenance. I generally delete all jobs after reconciling with Default, unless told otherwise.
Anyway, this issue got me wondering what the harm is if the locks were simply to remain when I perform the above maintenance procedure. My thought is that if the edits are already posted it shouldn't be a problem but, again, it still bugs me that the locks remain.
I have attached the workflow for maintenance that I use. I start at the bottom of page 5 and work to the end.
Okay - well, I look forward to hearing from you to get your perspective. At your convenience, of course. I'm tickled you answered my post!
Best regards,Ana
