Viewing list of items of a Query Backed Relationship field

[ptc-5208303]

Hello Everyone,

I am new to Integrity and have the below mentioned problem to be solved:-

I have created a query backed relationship field (QBR), lets call it XYZ.

XYZ is supposed to generate a list of items (based on an already defined query) of type ABC.

This query does contain 5 items and can be generated. But when used in a QBR, am not able to see the lsit of items.

XYZ is one of the fields of type EFG.

IJK is another field of EFG and when creating a new item of type EFG, this field IJK has to be checked against the entries listed in XYZ. If it is present in the lsit, the item of type EFG is not allowed to be created.

The problem here is that I am unable to see the list of XYZ anywhere, either while creating the type EFG item or afterwards.

Could someone please help me out here and tell me how exactly a QBR can be set up and where to see the generated table of items?

Thanks!

[matt_giltaji]

Hi Sunil,

QBR fields generate lists by taking the generic query and filter it down based on the fields on the current item. (This is handled by the field correlation section of the QBR field set up.) You can view this by looking at an item where the QBR field is visible.

If you are not seeing anything in the QBR field on an item, you probably want to check how the correlation is set up.

I am not 100% sure if the QBR is the best way to achieve your use case, you might be better off with a custom trigger script that runs the query for XYZ and performs the business logic check against IJK, and aborts if the item should not be created.

You also may want to look into the "duplicate detection" functionality available in Integrity 10.1 and up and see if that solves your use case without needing a QBR or a custom trigger.

Here is an example for how QBRs are working for us.

We have some single-select IBPLs (item back pick lists... basically every item of the given type that matches a set of fields and states is a value in the picklist) present on item type "Foo". We have a business need to determine which "Foo" items have selected "Bar" as the IBPL value.

We could write a custom query for this, and grab all the items where Type = "Foo" and IBPL="Bar", but that becomes a lot of work as we would need to redo this query for each different value of the IBPL.

We could also write a chart or report that queries for every "Foo" item and groups the results based on the IBPL, but that becomes inefficient as we might need to pull 1000+ "Foo" items to find out which 3 of them have "Bar" for the IBPL.

We could also query for every "Foo" item, add the IBPL column to the query results, export to excel and process there but again we have to pull everything and that does not scale well.

As a solution for this, we create a QBR which works as a backwards IBPL. The query for this IBPL is all "Foo" items. The correlation for this QBR is that the IBPL field on "Foo" = the ID of the backing type (type used as the IBPL values). Then we add the QBR field to the backing item type and now we can open any of the backing items and immediately see which "Foo" items have this particular item selected in their IBPL field.

Does that help?

Matt

[ptc-5208303]

Hello Matt,

Thank you for your reply. We finally found another way to implement our business logic that does not include the use of QBR. I think my settings of the field correlation section of the QBR field set up was wrong for the error to have occurred as you suggested. Unfortunately I am a bit pressed for time at the moment and will be able to look into the problem I had with the QBR only later. But thank you very much for your answer to my question.

With best regards,

Sunil