0
Answered

Attribute Table Mapping Request

Todd Turner 2 years ago in UNIFYBroker/Aderant Expert updated by Matthew Davis (Engineering Manager) 2 years ago 6

I have a customer that has modified their database schema and has had a flow on effect to IDB where it will not run as there is an extra column.  Problem being the extra column has been added in multiple places and need to be able to isolate exactly which db/table/column each attribute connects to so I can inform the customer which instance of the extra column is causing IDB to fail so they can remove.

Affected Versions:
Fixed by Version:

Answer

+2
Answer
Under review

Hi Todd,

Out of the 5 tables listed in the ticket, i've done a mapping of which tables expect the field based on the OBSOLETE_1 field:

HBM_NAME: No

HBL_WORK_GROUP: No

HBM_PERSNL: Yes

HBM_ADDRESS: No

HBM_NAME_PEOPLE: Yes

So if they've added the field to HBM_NAME, HBM_WORK_GROUP or HBM_ADDRESS then it's likely one (or more) of these tables is what's causing the issue. The connector gets relational data from all of the tables listed, so it's unlikely to just be a single table.

GOOD, I'M SATISFIED
Satisfaction mark by Todd Turner 2 years ago

Hi Matt,

The customer is shared screen only so I can't get the configuration at the moment.

The error the customer is receiving is "unexpected column obsolete_1 in table".  The additional column is in 5 places within the same database with the same name.  The customer is asking us which particular table IDB uses to obtain information so they can remove the column from the specific table that IDB is using.  So I'm trying to obtain a summary of which table/column within the Aderant Expert database is used so the correct extra column is removed.

+2
Answer
Under review

Hi Todd,

Out of the 5 tables listed in the ticket, i've done a mapping of which tables expect the field based on the OBSOLETE_1 field:

HBM_NAME: No

HBL_WORK_GROUP: No

HBM_PERSNL: Yes

HBM_ADDRESS: No

HBM_NAME_PEOPLE: Yes

So if they've added the field to HBM_NAME, HBM_WORK_GROUP or HBM_ADDRESS then it's likely one (or more) of these tables is what's causing the issue. The connector gets relational data from all of the tables listed, so it's unlikely to just be a single table.

+1

This is perfect, figured it would be multiple tables but wanted to be able to take that back to them.  Thanks Matt!

Hi Todd,

Has there been any update on this?

Hey Matt,

With regards to the above request, the information was what was required.  There may be ongoing work as a result of this, but I assumed that would be a separate discussion?