AIM Internal DB Fields: xxx_RMA Why?

Jaymer

We know about the 3 fields used by AIM internally to manage relationships;
for example,
cust_REN,
cust_RID,
cust_RMA

i think of them as
ENTITY
ID
?? What would MA stand for, and, more importantly, what is this used for? BruceL taught me how to load these fields when doing SQL imports, but I found out doing normal Imports through aware blanks out the RMA field, but it gets loaded by doing "Relationship" imports. This showed me an error in a value I was stuffing in there, AND YET the system still works.

There is no index built on the RMA field.
Showing relationships in aware still seems to work without it.

So the simple Q is... what exactly is the RMA field used for - and what breaks if its empty?
thx
jaymer...

Jaymer

And the reason this is important to me...

I'm doing regular imports to refresh data from a production system, when I add/update records this RMA field is blanked out.
I'll need to perform a 2nd import of "Relationships" to restore this field and I'm not sure if its necc.

PointsWell

RMA shows the relationship backwards

BO REN gives a link to another object
BO RMA gives the link back from that object to this one

Look at the database entries for an object with an owning relationship to another object.

My top level BOs have a Tenant owning relationship
e.g. Contact.ob_Tenant the Tenant then has a 1:M relationship back to Contacts via Tenant.om_Contacts

The contact record has:
Contact.ob_Tenant_REN - shows the related BO: Tenant
Contact.ob_Tenant_RID - shows the ID of the record on the Tenant BO
Contact.ob_Tenant_RMA - shows the name of the field on the Tenant that owns this record: om_Contact

It also applies where they are peer relationships with bi-directional relationships (i.e. when you want to be able to refer back and forwards).

I would imagine, but have not tested, that if you omit this RMA field then you won't be able to find all the Contacts related to a particular Tenant (in the above example)

Jaymer

PointsWell wrote
I would imagine, but have not tested, that if you omit this RMA field then you won't be able to find all the Contacts related to a particular Tenant (in the above example)

well, before i posted i DID DO some testing.
since the field isn't indexed, its not very useful from what I can tell.

I tested it on CUSTOMER/ORDER schema.
Using default generated forms, I could view the customer and see a table of orders. (om_Orders)
And I could view an order, and see the relationship to the customer. (ob_Customer)
All seemed to work fine, which is why I'm asking.

When I import an order, one of the fields is "Order.ob_Customer.CustID".
After the import, the data looks like this:

You can see the RMA field is NULL.
The RMA field DID have a value before, "om_Orders", but the import removed it. That doesn't make sense why, unless I actually import an Order pointing to NO Customer (which doesn't make sense in itself).
And yet all still works fine with the NULL field.

In order to restore this field, I'd need to do another import of Relationships, in this format:
O.Order_Num,O.ob_Customer.ID
656936,200023

Then the data becomes this:

But its another point of failure (the 2nd import) and I'd rather not do it until I know why its important/mandatory.

BLOMASKY

Some answers James.

1st, that field is ONLY required if when you created the relationship if you told aware to create the one in the parent.

2nd, edit your SQL (you are using mysql, right?) and have both the RMA and REN have a default value since they are constants.

3rd you would never index a column where every value is identical. Huge performance hit when inserting records (assuming you have a lot of rows.)

... Slight off topic here, but any table that has a lot of rows, that is getting a lot of records inserted, since aware will create an index for each relationship, I edit them to make them 2 column indexes with the ID as the 2nd column. That way each one will be unique. This really only makes a difference if there are FEW parent records. So, for instance, in my customer table, I have a TERMS relationship. There are about 30 terms with 2-3 used by 90% of the customers. This is a great place to update that index to a multi-part index.

back on topic...

4th, I have not tested it yet, but if you leave that field null, can you ever say:
IF Customers.om_Orders WAS CHANGED

I have not tried this, but I would assume aware would have NO idea that it should be executed if the record was null, but what do I know?

Bruce

aware_support

The RMA column is only used in certain rather esoteric relationship scenarios that are difficult to explain. See if you can work it out from the following:

// It is possible that several attributes of one business object have the same
// matching attribute in another object. For example, Timesheet object may have
// 7 references to DayRecord object: Timesheet.Monday, Timesheet.Tuesday etc
// DayRecord object, however has only one reference to the Timesheet object:
// DayRecord.Timesheet. Therefore Timesheet object has 1 matching attribute in the
// DayRecord object and DayRecord object has 7 matching attributes in the Timesheet object.
// If DayRecord.Timesheet attribute is persisted and Timesheet.Monday, Timesheet.Tuesday etc
// are not, then DayRecord.Timesheet has to store not only the id of the Timesheet object
// that is related to the DayRecord, but also the name of the matching attribute in the
// Timesheet, for example, Monday, Tuesday etc