Skip to main content
Solved

error : standard attribute refered to in table t is not an approved persistent Custom Attribute.

  • November 29, 2024
  • 1 reply
  • 248 views

REOGIRARD
Sidekick (Customer)
Forum|alt.badge.img+8

Hello

I’m working on migration of IFS V8 to IFS Cloud 24.1.4 and I’m publishing custom attributes.
On InventoryPartInStock entity, I have a custom attribute which is a readonly.
For this, we use the following statement (adapted to the new db structure) :

1SELECT
2 pol.cf$_gross_weight_rw
3FROM
4 purchase_order_line_cfv pol
5 INNER JOIN receipt_inv_location ril ON pol.order_no = ril.source_ref1
6 AND pol.line_no = ril.source_ref2
7 AND pol.release_no = ril.source_ref3
8 INNER JOIN inventory_part_in_stock ipis ON ril.contract = ipis.contract
9 AND ril.part_no = ipis.part_no
10 AND ril.configuration_id = ipis.configuration_id
11 AND ril.location_no = ipis.location_no
12 AND ril.lot_batch_no = ipis.lot_batch_no
13 AND ril.serial_no = ipis.serial_no
14 AND ril.waiv_dev_rej_no = ipis.waiv_dev_rej_no
15 AND ril.eng_chg_level = ipis.eng_chg_level
16 AND ril.activity_seq = ipis.activity_seq
17WHERE
18 ipis.contract = :contract
19 AND ipis.part_no = :part_no
20 AND ipis.configuration_id = :configuration_id
21 AND ipis.location_no = :location_no
22 AND ipis.lot_batch_no = :lot_batch_no
23 AND ipis.serial_no = :serial_no
24 AND ipis.eng_chg_level = :eng_chg_level
25 AND ipis.waiv_dev_rej_no = :waiv_dev_rej_no
26 AND ipis.activity_seq = :activity_seq

And following request arguments : 

1v.contract, v.part_no, v.configuration_id, v.location_no, v.lot_batch_no, v.serial_no, v.eng_chg_level, v.waiv_dev_rej_no, v.activity_seq


When validating the attribute before approval and entity synchronization, I got the following error :

 

The column configuration_id refered to in table t is not an approved persistent Custom Attribute.

 

The problem is, configuration_id is not a custom attribute, but a standard attribute of the table.
Seen on the view, and on db, the field is available and has data.


What I tried is to replace the sql statement to test the argument on dummy table :

1SELECT :configuration_id FROM dual

The issue is still there, and I can’t figure out what is the problem to fix.
Removing the argument and the where clause, keeping the join on the field make the statement working.
But this is not the good solution, we need configuration_id as argument.

Best answer by REOGIRARD

Issue fixed.
There was an activated view which did not had the configuration_id field resulting in this issue as we were using configuration_id as argument to publish the custom field.

View original

1 reply

REOGIRARD
Sidekick (Customer)
Forum|alt.badge.img+8
  • Author
  • Sidekick (Customer)
  • 26 replies
  • Answer
  • December 10, 2024

Issue fixed.
There was an activated view which did not had the configuration_id field resulting in this issue as we were using configuration_id as argument to publish the custom field.


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings