Emerson Exchange 365

• Not Answered

Item is currently being updated by ADMINISTRATOR on node PROPLUS

Hi, everyone!

I'm using DeltaV 11.3 and I have a problem, when I try to open a control module, it has ERROR: Item is currently being updated by ADMINISTRATOR on node PROPLUS running 'Control Studio'.

I've been tried to troubleshoot:
1. Rebooted a system
2. Disconnected ALL Data Base Connection in Database Administration
3. Tried to login with different username
4. Killed cs.exe in task manager
5. Downloaded setup data to ProPlus
6. Extended Clean to Database in Database Administration

I asked for help from Technical support service in my country, they offered me to remove DataBase and recover from daily export, but
I can't do it because System might need a full load of nodes.
There is any solution to this trouble???

Thanks.

• DeltaV #DCS
• ControlModules

Dmitrii Kapitonov

• 31 May 2019 4:15 PM
• Cancel

6 Replies

• István Orbán

  

  • 6 Jun 2019 11:10 AM

  Try to create a module in AREA_A with the same name as the module you are trying to access. This should not be possible and you should get an error, but it might get the original module "unblocked".

  • Cancel
• Nabil BOU

  

  • 6 Jun 2019 4:19 PM

  .

  • Cancel
• Andre Dicaire

  

  • 6 Jun 2019 9:20 PM

  In reply to Nabil BOU:

  Dmitri,
  
  I suggest the very first thing you should do is make sure you save your current database and the DeltaV/DVDATA folder. Perform a complete export of the system and save the Powerup directory from DVDATA. Then if you want to attempt some of these suggestions, you know you have saved your system in case recover is need.
  
  Next, try to complete all pending download activities to clean up the state of the database. Do another save at this time so you don't recover with pending downloads. ( I always start by saving what I have before trying to repair it incase my repair actions make things worse. It usually when you skip the "save your work" step that something actually goes wrong)
  
  The issue you describe is usually the result of an abnormal closure of Control Studio, resulting in a lock on the object (module) not being removed. Typically this is resolved by using the Database Administration tool to remove database connections. However this did not work for you.
  
  You also ran a Full Database Clean, which performs and OOTidy and rolls back any incomplete transactions. This too did not work.
  
  Your service provider suggested recovering your database from back ups. in terms for expediency, this is not a bad suggestion . Your choice is to follow trial and error suggestions from a forum like this, and maybe get lucky, cut your losses and recover the system so you can move forward.
  My rule: If someone can confirm they experienced this same issue and can offer a precise fix that worked, I would try that. But if someone is trying to be helpful but has no confirmation that their suggestion will work, the production system is not where I would experiment.
  
  You might further compromise the system configuration following well meaning advice. And find yourself back to recovering from Backup. Good thing you've secured a good back up.
  
  Your recovery procedures are just as important as your Backup procedures. This is a good time to put these to the test. if you are not sure how to recover so that you preserve download status and do not need to download your system, you should seek out assistance. Your backup is only as good as your ability to recover the system with it.
  
  Good luck.

  Andre Dicaire

  • Cancel
• Dmitrii Kapitonov

  

  • 3 Nov 2019 11:17 AM

  In reply to Andre Dicaire:

  Thank you for your reply, Andre.
  I can try to do it when the plant will be stopped for maintenance, I'm afraid to create problem for production. Now I removed the links from this module to avoid uncontrolled action.

  • Cancel
• Dmitrii Kapitonov

  

  • 3 Nov 2019 11:19 AM

  In reply to István Orbán:

  Thank you for your reply.
  Unfortunately this didn't work

  • Cancel
• Youssef.El-Bahtimy

  

  • 3 Nov 2019 12:26 PM

  In reply to Dmitrii Kapitonov:

  Depending on the cross communication complexity of the module in question, it may be easier to create a copy of the problem module, right down to the I/o configuration, deassign the problem module from control, (or if the database won't let you, effectively disable it on line) then update all external references in other modules to point to the new module. Obviously a shut down and up front work is required, but it could be less risky than a full database restore .

  • Cancel