DB Trigger on the ca_company skips inserts and updates of custom fields

[Kevin Christopher Chacon Campos]

Hi, I have encountered a limitation on the ca_company table and I would like to know if the workaround I've used could lead to problems in the future.

The case is, I added a custom field to the ca_company table using the Web Screen Painter and there were no issues, but when trying to insert or update it, the value is not saved. I have found a couple of database triggers over the table (ca_tr_ins_ca_company_division and ca_tr_upd_ca_company_division) which causes only default fields to be inserted or updated.

Since we needed to update the values of the custom field, I temporarily deactivated the triggers, and once the field was updated, I reactivated it, now I'm wondering what would be the implications of having that custom field on that table, are those triggers there only for product integration (in which case I don't think we would have a problem, besides SDM we only use EEM) should I add the custom field to the trigger so it can always be inserted or updated?

Looking forward to reading your thoughts on this matter, thanks in advance.

[Kyle R]

We actually have some documentation on "Drop and Restore Constraints" against the ca_company table here:
https://techdocs.broadcom.com/content/broadcom/techdocs/us/en/ca-enterprise-software/business-management/ca-service-management/17-2/administering/configure-ca-service-desk-manager/managing-your-database/drop-and-restore-constraints.html

If what you're doing is similar, then there shouldn't be an issue, providing you take care.

However, if I found a table that did odd things like that, I'd consider making up a new table and putting in a cross reference, rather than touch a table that has unusual update requirements.

Kyle_R.

[Kevin Christopher Chacon Campos]

Thank you Kyle, I've reviewed the sql files and it seems they just drop/create fk and date constraints on the base fields, but they don't touch the triggers I mentioned in the post, I'll keep the document bookmarked though, I'm sure it will be helpful soon. As for the creation of a new table, I totally agree with you, and it's what I proposed instead of sticking to this workaround, sadly it was another administrator who did the change and anybody noticed the issue until it was pushed to production.