CMDBuild Forum

Deleting cards with relations

Old Versions
#1

Hi There,

I have attempted to delete a redundant card from CMDBuild, however I'm receiving an error stating that the card cannot be deleted if it is having relations. I have checked the relations tab on the card and nothing is listed, in addition I have no other active cards other than a cloned card within the same sub-class.

The class does have a domain relationship with other classes, however no relationships exist for that specific card.

Can someone confirm if this is a bug? Alternatively, could anyone suggest a workaround?

Thanks,

Jamie

#2

Hi Jamie,

we are not aware of any such bug. We need some more information to try and solve your issue. What CMDBuild release are you using? Is it a subclass or a top-level class?  Can you post the relevant portion of the log file (perhaps with debug activated)?
Paolo
#3

Tecnoteca ha scritto:

Hi Jamie,
we are not aware of any such bug. We need some more information to try and solve your issue. What CMDBuild release are you using? Is it a subclass or a top-level class?  Can you post the relevant portion of the log file (perhaps with debug activated)?
Paolo

 

Hi Paolo,

 

Can you confirm how I find out which version I'm running? I believe it's 1.5 but i'm unsure what patch version I'm at.

 

The class structure is as follows:

 

Superclass: esccmdb

  class: location (type=Standard - Inherits from esccmdb)

    card: INACT

 

Attributes on card:

(Inherited) Global UID: [NULL]

Location Name: "INACT"

Address Line 1:

[NULL]

Address Line 2: [NULL]

Address Line 3: [NULL]

City / Town: [NULL]

Postcode: [NULL]

(Inherited) Description: [NULL]

 

Domains: 1:n

Target: Hardware superclass (no records but has sub-classes)

 

Error message when attempting to delete the INACT card: "Can't delete cards having relations"

 

Log:

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.cmdbuild.filters.AuthFilter.doFilter(AuthFilter.java:54)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.cmdbuild.filters.PatchManagerFilter.doFilter(PatchManagerFilter.java:28)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.cmdbuild.filters.ConfCheckFilter.doFilter(ConfCheckFilter.java:31)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.cmdbuild.filters.TranslationFilter.doFilter(TranslationFilter.java:37)

        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)

        at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:857)

        at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)

        at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

        at java.lang.Thread.run(Thread.java:679)

ERROR 2012-05-18 10:56:37 [jsonrpc ] A org.cmdbuild.exception.ORMException occurred calling method class org.cmdbuild.servlets.json.management.ModCard.deleteCard: ORM_CANT_DELETE_CARD_WITH_RELATION

 

Thanks,

Jamie

 

#4

Tecnoteca ha scritto:

Hi Jamie,
we are not aware of any such bug. We need some more information to try and solve your issue. What CMDBuild release are you using? Is it a subclass or a top-level class?  Can you post the relevant portion of the log file (perhaps with debug activated)?
Paolo

 

In addition, here are the logs from postgresql:

 

STATEMENT:  UPDATE "location" SET "Status" = 'N' WHERE ("location"."Id" = 58)

WARNING:  there is no transaction in progress

ERROR:  column "id" does not exist at character 45

STATEMENT:  DELETE FROM location WHERE name='INACT' AND Id='58';

ERROR:  column "Id='58'" does not exist at character 45

STATEMENT:  DELETE FROM location WHERE name='INACT' AND "Id='58'";

ERROR:  invalid input syntax for type boolean: "Id=58" at character 45

STATEMENT:  DELETE FROM location WHERE name='INACT' AND 'Id=58';

ERROR:  CM_RESTRICT_VIOLATION

CONTEXT:  SQL statement "SELECT _cm_restrict(OLD."Id", TableId, AttributeName)"

        PL/pgSQL function "_cm_trigger_restrict" line 8 at PERFORM

STATEMENT:  UPDATE "location" SET "Status" = 'N' WHERE ("location"."Id" = 58)

ERROR:  CM_RESTRICT_VIOLATION

CONTEXT:  SQL statement "SELECT _cm_restrict(OLD."Id", TableId, AttributeName)"

        PL/pgSQL function "_cm_trigger_restrict" line 8 at PERFORM

STATEMENT:  UPDATE "location" SET "Status" = 'N' WHERE ("location"."Id" = 58)

ERROR:  CM_RESTRICT_VIOLATION

CONTEXT:  SQL statement "SELECT _cm_restrict(OLD."Id", TableId, AttributeName)"

        PL/pgSQL function "_cm_trigger_restrict" line 8 at PERFORM

STATEMENT:  UPDATE "location" SET "Status" = 'N' WHERE ("location"."Id" = 58)

 

#5

Hi Jamie,

the patch version you are using is written in the META-INF/maven/org.cmdbuild/cmdbuild/pom.properties file.
If I understood your problem correctly, you cannot delete a card that does not seem to have any relation (the class has a domain but its relations tab is empty). Can you confirm this? Have you used the same domain for more than one reference attribute?
Paolo
 
#6

Tecnoteca ha scritto:

Hi Jamie,
the patch version you are using is written in the META-INF/maven/org.cmdbuild/cmdbuild/pom.properties file.
If I understood your problem correctly, you cannot delete a card that does not seem to have any relation (the class has a domain but its relations tab is empty). Can you confirm this? Have you used the same domain for more than one reference attribute?
Paolo
 

Hi Paulo,

 

version=1.5.3

 

Yes, I have now also been able to delete all domains associated with that class, yet when I try to delete any records I get the same error as when the class did have a domain.

 

I was able to delete the domain by removing any reference attributes referencing the origin class.

 

I still receive the same error.

 

Thanks,

Jamie

 

 

 

#7

Hi Paulo,

 

I have managed to resolve this issue, the error reported back there was a relationship locking the deletion of the card. However, upon checking, this couldn't be found.

 

I then checked my locations geographical attribute and it wouldn't allow me to delete this due to data being in the class already.

 

I then went into data management and couldn't find the location data as my current directly was the root of the class structure instead of the class itself, so the geographical attribute data wasn't showing on the map.

 

I then changed to the correct class (in this case, locations) and removed the point on the map for the geo attribute, this then allowed me to delete the card without error.

 

Perhaps in future releases considering a change to error reporting, something to state that GIS data is contained within the card which needs to be removed before removing the card? Instead of the relationship error.

 

Many Thanks,

Jamie

#8

Hi Jamie,

 
I honestly forgot about the GIS attributes, and I admit the error message is not user friendly. We will definitely consider fixing it in a future release.
 
The technical reason you were receiving that error is that it was decided to put the GIS data in its own space, so those attributes are a simple class with a foreign key pointing to the original class.
 
Paolo
 
#9

Tecnoteca ha scritto:

Hi Jamie,

 
I honestly forgot about the GIS attributes, and I admit the error message is not user friendly. We will definitely consider fixing it in a future release.
 
The technical reason you were receiving that error is that it was decided to put the GIS data in its own space, so those attributes are a simple class with a foreign key pointing to the original class.
 
Paolo
 

Ah I see, okay thanks for your help Paolo.

 

Jamie