Warning in Log viewer related to the BRO component

Hi,

I made some minor changes to a Area object which resulted in a error in the log  - "DRE51006 - CBaseRuntimeObject::InternalSetAttribute - Sets are not allowed on a quarantined object." It relates to a component called BRO. What does the BRO component related to? and what does it mean that a object becomes quarantined?

note: "DRE51006" is the name of the area object. 

Parents
  • Most likely a script on this area object DRE51006 is running into an exception which is resulting the object quarantine. Review the scripts on this are object to identify the problematic script and fix the code causing exception.

  • Hi Mr. Srinivasa, thank you for your help.  I ended up restoring a backup.  This definitely had to do with a script but I wasn't able to identify what was wrong with it.

    The case was like this, there was an inherited script running on the area object. It was a very simple script. It's purpose was to change a value on a string attribute, it was running periodically every 10 minutes but it was not locked so any changes to that script were not propagated. Derived instances from the area template where the script was defined were around 200. I needed to change the original value for the string attribute for all the area objects.  So what I did was locking the script in the template and propagating it to all its children with a new string value defined.  

    When deploying one of the area objects, (DRE51006) it got quarantined. I tried unlocking the script and changing the string value to the previous value. But that didnt help.

    I did some more work trying to fix it. Here is a screenshot with more comprehensive results when deploying more of the  area instances with the propagated changes. This shows all warning and errors related to the deployment 

      

    I gave up debugging it and restored a backup.  I guess sometimes it is not possible to identify the root cause. But thank you for your help and taking time to answer!

Reply
  • Hi Mr. Srinivasa, thank you for your help.  I ended up restoring a backup.  This definitely had to do with a script but I wasn't able to identify what was wrong with it.

    The case was like this, there was an inherited script running on the area object. It was a very simple script. It's purpose was to change a value on a string attribute, it was running periodically every 10 minutes but it was not locked so any changes to that script were not propagated. Derived instances from the area template where the script was defined were around 200. I needed to change the original value for the string attribute for all the area objects.  So what I did was locking the script in the template and propagating it to all its children with a new string value defined.  

    When deploying one of the area objects, (DRE51006) it got quarantined. I tried unlocking the script and changing the string value to the previous value. But that didnt help.

    I did some more work trying to fix it. Here is a screenshot with more comprehensive results when deploying more of the  area instances with the propagated changes. This shows all warning and errors related to the deployment 

      

    I gave up debugging it and restored a backup.  I guess sometimes it is not possible to identify the root cause. But thank you for your help and taking time to answer!

Children
No Data