Before you proceed with deletion or updates, please do the following.
1) Backup the Database
2) backup the forms data before any record delete or update
I am sure you have followed the KA Remedy - Server - There are too many server names showing up in my Centralized Configuration menus
Also make sure the document steps were taken care when you cloned the environment.
BMC has too much lacking in this area, no proper documentation and too much references around. If you delete any information accidently from these forms then you are done, BMC has no solution for you. I have been shouting for many years and no one listens and document don't cover everything.
I will suggest to go through these forms behind the scenes and make backup of all records before deleting any entries.
1 of 1 people found this helpful
Actually, why to delete the entries with previous server name. He is gone so just replace everything with new server name.
To be really sure I did:
- Search through the whole ARSystem DB for the old server name and replace relevant configuration forms data (you can find a script for this)
- Search through all files content for the old server name and replace that (I used e.g. total commander. in unix you can use grep)
1 of 1 people found this helpful
On Windows I also like BareGrep to give that greppy feeling.
Do you know what the purpose of the AR System Configuration Component form is suppose to do?
2 of 2 people found this helpful
AR System Configuration Component and all other AR System Configuration* forms are used in Centralized Configuration (CCS) feature in platform. This form is used for storing configurations for all components (server, plugin server, midtier, email, Smart IT, etc.) Component form is the parent form for all configurations and contains 1 entry per component instance e.g. 1 entry for server, 1 entry per every plugin server, and so on. There are also 2 other regular forms AR System Configuration Setting and AR System Configuration Component-Setting Mapping that are used for storing actual configuration key values and their mapping with the parent component record.
Coming to your original question "The question is would it be safe to delete all the old server name records? " >> Yes, it is safe to delete old server entry from this form. But before deleting this entry, you should also delete corresponding entries from other 2 forms using the GUID mapping. However, if you do not delete entries from these forms, they will just remain orphan. They will not cause any functional impact.
But, going back to your original problem, where email link contains old server name, it is probably not due to this configuration entry. It is probably one of the configuration values from current server's email config types configurations. You may want to check that too.
Hope this helps.
Appreciate your detailed explanation of CCS.
Last 2 week I have gone through this exercise and come to conclusion you should not delete entries, even before starting the new server, open the database and replace old server name with new server name and start the new server. I experienced going through different case scenarios to figure it out every other scenario failed, except the database level changes before starting the server.
Note: It took me many database restores to understand and come to conclusion
Sorry it took so long to get back to you guys. I'm going to take your solutions and try them out. I got side tracked and finally getting back to this issue of the midtier sending users to the old server when they click the link.
I'll keep everyone posted in a few, thanks for your input into this.
With regard to orphan records the above two articles (they are basically the same) mention that deleting records on the AR System Configuration Component form will trigger filters to delete records on the related AR System Configuration Component-Setting Mapping and AR System Configuration Setting forms. However, on my 18.05 system, those filters are attached to the AR System Configuration Component Setting form (which is a join form), so they wouldn't fire as indicated in the articles.
Would it be better to delete records from that join form instead of the ones those articles mention in order to prevent orphaned records? Do you have a query (SQL or otherwise) that would identify orphans?
Thanks in advance.
3 of 3 people found this helpful
Yes, you are right. Deleting record from AR System Configuration Component will not delete any child records. It will leave orphan records in remaining 2 forms. So, the best way is to first delete all entries from the join form AR System Configuration Component Setting for the unwanted component, and then delete the component itself from AR System Configuration Component form.
Here is some more detail on how to find out orphan record. I tried it internally, so providing the sql scripts with comments inline. Hope that doesn't cause any confusion.
-- example data created via AR System Configuration Component Setting join form
-- component type = com.test
-- componet name = component1
-- setting1 = value1
-- setting2 = value2
select schemaId, name from arschema where name like 'AR System Configuration Component' or name like 'AR System Configuration Setting' or name like 'AR System Configuration Component-Setting Mapping'; -- find schema ids
-- 8 AR System Configuration Component
-- 6 AR System Configuration Component-Setting Mapping
-- 21 AR System Configuration Setting
select * from T8 where C3201 = 'com.test' and C3200 = 'component1'; -- finds 1 row for com.test component
select * from T6 where C3207 in (select C179 from T8 where C3201 = 'com.test' and C3200 = 'component1'); -- finds 2 rows containing mappings for component guid and setting guid
select * from T21 where C179 in (select C3206 from T6 where C3207 in (select C179 from T8 where C3201 = 'com.test' and C3200 = 'component1')); -- finds 2 rows for settings
-- now delete the component com.test/component1 from AR System Configuration Component form, just to create orphan data for test purpose
-- orphan records will stay in both other forms, find them
select * from T6 where C3207 not in (select C179 from T8); -- find orphans in AR System Configuration Component-Setting Mapping
select * from T21 where C179 in (select C3206 from T6 where C3207 not in (select C179 from T8)); -- find orphans in AR System Configuration Setting
select * from T21 where C179 not in (select C3206 from T6); -- find orphans in AR System Configuration Setting
-- above orphan records can be deleted safely - I suggest do it via midtier so that audit history is retained
Perfect! Thank you.
I don't understand BMC here. In the newer versions relationships between tables can be defined and for some Tablets BMC has already done. So there is an OOB mechanism at AR level to keep dependent forms consistent.
Please use this OOB for ccs and spare your customers such instructions. It should be a no brainer for every BMC Developer.
Thank you Stefan Hall for the feedback. Please keep it coming. I believe you are referring to the "Associations" feature that can help define parent-child kind of relationships. While it may be possible to implement it as such, it cannot be implemented in a foolproof way due to backward compatibility reasons. Some components including custom programs by customers may be creating settings first and then actual component. The old system allowed that, so does new system. This wouldn't have been possible if the 3-way join interface was always used to create component and settings. So, it's difficult to make it foolproof.
Also, I provided above information related to databases only for informational purpose. It is not expected to go to the database and find or delete records. The first part of my earlier message informs about how to use 2 forms via midtier to avoid any inconsistencies. If it is followed, there is no reason to go to the database at all.
Hope this helps.
thank you for your explanation and "associations" is the correct term on AR level.
However, I do not understand BMC here. ccs is relatively new and backware compatibility should no reason to prevent general improvements. Currently the system is already a configuration monster and with this setting it will never get better. I don't think that it should be the job of customers to keep system information, forms synchronized. If it doesn't work with assignment - I don‘t believe, then implement appropriate filters.
The requirement is very simple, remove a server with all its dependent information from ccs - just one click and not for each component or at DB level.