• State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 95 subscribers
  • Views 10829 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 6 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.

  • 0 over 6 years ago
    I have the same issue, did you manage to fix yours?
  • 0 over 6 years ago

    I would check two things:

    • Is the DB queue operating normally in your environment?
    • Check if any error is occurring in the database journal?
  • 0 over 6 years ago

    Hi Markus,

    There are indeed errors in the journal, but not sure what to make of them

     

     

    (execute slot single)50000           0              re-throw in Procedure QBM_ZConstraintEnable, Line 950000   0              re-throw in Procedure QBM_PConstraintEnable, Line 1350000       0              re-throw in Procedure QBM_PConstraintChange, Line 1450000             0              re-throw in Procedure QBM_PExecuteSQL, Line 9547  0                detected in Procedure QBM_PConstraintChange, Line 1

    The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "QER_RFRL1201". The conflict occurred in database "<DBNAME>", table "dbo.BaseTree", column 'UID_Org'.

    Code starting with:

    alter table "BaseTreeCollectionF" with check check constraint QER_RFRL1201

  • +1 over 6 years ago
    It seems like you created an invalid schema extension as some parts of your extension are conflicting with one of the foreign key constraints on Basetree.UID_Org.

    Please contact support to help you out with this.
  • 0 over 6 years ago
    Thanks Markus, any way of investigating ourselves to find out which schema extension is causing the issue?
  • 0 over 6 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?
  • +1 over 6 years ago
    Sorry, but the only thing I know is that the FK constraint QER_RFRL1201 is defined on BaseTreeCollectionF for the column UID_Org as you are able to find out with something like SQL Server Management Studio.

    What I assume is, but this is a wild guess, that you tried to create a new view based on BaseTree and your constraints conflict with the one here.

    But this would need further investigation and this is why I recommended contacting support.
  • 0 over 6 years ago
    I am quite sure this is a bug..the schema extension that was throwing this error in my development environment became 100% safe once transported in test. I think sometimes development environment became "dirty" due to heavy work on it.
  • 0 over 6 years ago
    I found that for some reason BaseTreeCollectionF had some UID_Org which were not present in BaseTreeCollection. I removed those UID_Orgs and then the alter table command ran fine.

    I'm now getting similar errors in other basetree tables and I suspect somehow the other basetree tables have got data which isn't present in the parent basetree table. I'm removing these entries - so it looks like a data issue