uCMDB v10.01: resources count = 2 and not 1 as expected

Hi Gurus,


In our uCMDB v10.01 system, I create a Jython script "test.py".

Later, I had to rename the script according to our name convention "Test.py".


When I look in the GUI I see both scripts "test.py" and "Test.py".


They have the same code and I can only change the code from the "Test.py" script.

If I change the code in "test.py" and save the file, all modifications are ignored.


Also I can not delete the "test.py" file or "Test.py".


In the "error.log" file the following statement is written: 


2014-02-11 13:47:35,062 [qtp572165583-83] (AutoDiscoveryUserManagerImpl.java:1256) ERROR - Failed removing resource test of type 3 since existing resources count = 2 and not 1 as expected.


Does anybody has a clue to solve our problem?


I do not care if both scripts are deleted. I can recreate the "Test.py" again.


Thanks in advance.


  • This is not a known problem. 

    I'd suggest opening support case.

  • Thanks for your respond.


    I cannot open a support call. They client does not want to share his SAID.

    And I have a feeling talking to a wall convicing them to provide it.


    I reproduced the situation on a clean uCMDB installation.

    I have exactly the same problem. So I should not be the only one, with this problem.


    - Rode 

  • Dear Rode,

    The way you have patch/help on post-release version, is providing the SAID.

    I can't help here...

    I'll inform R&D on the problem you found.

  • I found a way to get rid of the duplicate resource.


    It is a very dirty way, but it did the trick. I will monitor the system to see if this does not unstable the system.


    This is what I did.


    I downloaded the free version of EMS SQL Manager for SQL Server.

    And made a connection to the database.


    In the table CDM_DISCOVERYRESOURCE_1, I found the resource with the same name but one with upper-case and I with lower-case. This was my issue.


    I added a letter at the end of the value in the column A_DISPLAY_LABEL and in the column A_NAME of one of the resource.


    After a refresh of the GUI of the uCMDB the resource was changed in the GUI and I could delete it from the GUI.


    I did not want to delete the resource straight from the database, because I do not know all the dependencies.

    As I said I did the trick for me.  


  • Well done! That what support was doing for you. I'd like to notice, that this is unsupported way of doing things :).

    Anyway, nicely done...

  • I ended up having this same issue and applied your fix with success.


    I'd like to add another symptom that occurs when this happens: Each time a change is committed to any discovery or integration-related resource or even a schedule in UCMDB, the duplicated files are sent back to the probe to be saved again.


    In one extreme case, this led to a content pack package being sent to the probe almost every time someone saved a change to an integration point, job schedule or discovery resource, overwriting changes made to out of the box packages (such as normalization rules) and causing the probe to restart to process new JAR files that came with the Content Pack.