• State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 97 subscribers
  • Views 14160 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Enable constraints 2, stuck DBQueue operation

Dario.Mariani
over 7 years ago

Hi all,

I'm using v 7.1

Eveytime I try to extend che 1IM schema with a new view or table, there is this operation "Enable constraints 2" in the DBQueue who needs to be executed before I can proceed, but this operation is stucked and won't be executed. I solved this "killing" the operation with Management Studio deleting it from the QBMDBQueueCurrent table, but I think there is a reason why it is there. What "Enable constraints 2" does and how can I prevent to blocking my system?

This happen only in the develop environment. If I remove the operation from the queue, extend the schema and transport with a change label the changes to test and production, the "Enable constraints 2" operation is ran with success and in few moments.

Parents
  • 0 over 7 years ago
    We had similar problems on one of our environments:

    re-throw in Procedure QBM_ZConstraintEnable, Line 9 50000 0
    re-throw in Procedure QBM_PConstraintEnable, Line 13 50000 0
    re-throw in Procedure QBM_PConstraintChange, Line 14 50000 0
    re-throw in Procedure QBM_PExecuteSQL, Line 9 547 0
    detected in Procedure QBM_PConstraintChange, Line 1
    The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "DPR_RFRL2482".
    The conflict occurred in database "D1IMDEV", table "dbo.DPRSchemaProperty", column 'UID_DPRSchemaProperty'.
    Code starting with:
    alter table "DPRSchemaAccess" with check check constraint DPR_RFRL2482

    We too couldn't figure out what the root cause was or how to fix it besides removing the scheduler entry. Something was trying to add a constraint that was already there IIRC.

    How is it even possible to "create an invalid schema extension" using the SchemaExtension tool? Are there things we need to keep in mind, that the tool will let us do but can lead to inconsistencies?
Reply
  • 0 over 7 years ago
    We had similar problems on one of our environments:

    re-throw in Procedure QBM_ZConstraintEnable, Line 9 50000 0
    re-throw in Procedure QBM_PConstraintEnable, Line 13 50000 0
    re-throw in Procedure QBM_PConstraintChange, Line 14 50000 0
    re-throw in Procedure QBM_PExecuteSQL, Line 9 547 0
    detected in Procedure QBM_PConstraintChange, Line 1
    The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "DPR_RFRL2482".
    The conflict occurred in database "D1IMDEV", table "dbo.DPRSchemaProperty", column 'UID_DPRSchemaProperty'.
    Code starting with:
    alter table "DPRSchemaAccess" with check check constraint DPR_RFRL2482

    We too couldn't figure out what the root cause was or how to fix it besides removing the scheduler entry. Something was trying to add a constraint that was already there IIRC.

    How is it even possible to "create an invalid schema extension" using the SchemaExtension tool? Are there things we need to keep in mind, that the tool will let us do but can lead to inconsistencies?
Children
No Data