> > Nope, the traceback talks about database constraint RHN_ENQUEUE_CID_FK > > which says there are records in the rhnErrataNotificationQueue table > > for this channels -- it's not about channel being child or having > > children. > > > > Jan is correct here. > > But when you check: > > CREATE TABLE rhnErrataNotificationQueue > ( > errata_id NUMBER NOT NULL > CONSTRAINT rhn_enqueue_eid_fk > REFERENCES rhnErrata (id) > ON DELETE CASCADE, > org_id NUMBER NOT NULL > CONSTRAINT rhn_enqueue_oid_fk > REFERENCES web_customer (id) > ON DELETE CASCADE, > next_action DATE > DEFAULT (sysdate), > channel_id NUMBER NOT NULL > CONSTRAINT rhn_enqueue_cid_fk > REFERENCES rhnChannel(id) > ON DELETE cascade, > created DATE > DEFAULT (sysdate) NOT NULL, > modified DATE > DEFAULT (sysdate) NOT NULL > ) > ENABLE ROW MOVEMENT > ; > > the 'CONSTRAINT rhn_enqueue_cid_fk REFERENCES rhnChannel(id) ON DELETE > cascade' shall ensure the all the rows from rhnErrataNotificationQueue get > deleted together the associated channel. > >From my point the table definition look good. > > So, the question is, how did you manage to delete the channel without > deleting appropriate rhnErrataNotificationQueue entries?
Actually, I haven't been able to delete the channel. "spacewalk-remove-channel" only handles base-channels seemingly (unless I'm missing some magic). And the WebUI is apprarently unable to do the work at present due to things previously mentioned in this thread. Andy _______________________________________________ Spacewalk-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/spacewalk-list
