MAM 7.6.1.2:

Is it possible to configure object structures so that they exclude rows? (via a WHERE clause)

Reason:

Staff use object structures like REP_WOPLANACT to create ad-hoc reports…and a CUSTOM_WO object structure to export to Excel (via application export).

But unfortunately, they keep misinterpreting the data when it comes to tasks:
1. They forget that tasks are WOs. It would be best to exclude tasks from both object structures.
2. On a side note: I plan to remove the ACT… fields from the object structures, since they don't include task actuals. I'll likely add custom ACT… fields to the object structures that do include task actuals.

If I could apply a WHERE clause to object structures, then that would help with avoid the situation in #1. 

(The source is More Maximo, but I don't know what the underlying post/webpage is.)

So as you said, that field obviously exists, at least for some people.

Question:

Is there any chance you could provide some info about what you're seeing?
  - Screenshot?
  - Database field name from via Alt+F1 (i.e. MAXINTOBJECT.xyz)
  - Version of Maximo that you're using

Sorry to ask so much, but I'm not sure how else to determine why I can't see that field.

Thanks!

I always recommend creating a new object structure instead of trying to change the existing. Most people don't realize this but changes to an object structure will prevent users from modifying any QBR based on it and existing reports would keep the logic you don't want (so it'd only help with new QBRs). 

Modifying existing object structures can also cause issues. There's a parent child hierarchy that gets built and a lot of time they look for the reference they expect (such as WORKORDER in this case) and if it's no longer part of the object structure the updatedb will fail. There are other issues too like their updatedb could add something back or remove something you added. It's typically easier and more reliable just to create your own (duplicating existing when possible).  

Thanks Steven. That's good to know.

Question:
In a previous comment about the RESTRICTWHERE field, you mentioned:
"…conditions can not always be converted to SQL."

Would you be able to expand on that point? Are conditions not written in real SQL?

Thanks.

I always recommend creating a new object structure instead of trying to change the existing. Most people don't realize this but changes to an object structure will prevent users from modifying any QBR based on it and existing reports would keep the logic you don't want (so it'd only help with new QBRs). 

Modifying existing object structures can also cause issues. There's a parent child hierarchy that gets built and a lot of time they look for the reference they expect (such as WORKORDER in this case) and if it's no longer part of the object structure the updatedb will fail. There are other issues too like their updatedb could add something back or remove something you added. It's typically easier and more reliable just to create your own (duplicating existing when possible).  

Hi Steven,

It looks like you were right. The "Data restriction condition" field (MAXINTOBJECT.RESTRICTWHERE) didn't work for ad-hoc reports (QBRs).

I added the BMXTKTNOTASK condition (:istask=0) to a custom report object structure . I used the report object structure in an ad-hoc report, but the report didn't exclude task records. So I think that tells us that "Data restriction condition" doesn't apply to ad-hoc reports.
 
"I don't think this would apply to QBRs (since you mentioned a report structure). I think this is purely for retrieval of data using the REST API since conditions can not always be converted to SQL."

"...conditions can be java classes (and automation scripts, which use a java class to launch your script). For example, BMXCREWID is a condition that uses a java class to determine if it should evaluate to true/false.

Because of the substitution variables and java classes, it doesn't seem likely that it would evaluate the condition in report object structure scenarios. But when you're retrieving data from the REST API you're interacting with MBOs so it can easily evaluate the condition logic."

Do we have any other options for filtering object structures for the purpose of ad-hoc reports?

Thanks.

Hi Steven,

It looks like you were right. The "Data restriction condition" field (MAXINTOBJECT.RESTRICTWHERE) didn't work for ad-hoc reports (QBRs).

I added the BMXTKTNOTASK condition (:istask=0) to a custom report object structure . I used the report object structure in an ad-hoc report, but the report didn't exclude task records. So I think that tells us that "Data restriction condition" doesn't apply to ad-hoc reports.
 
"I don't think this would apply to QBRs (since you mentioned a report structure). I think this is purely for retrieval of data using the REST API since conditions can not always be converted to SQL."

"...conditions can be java classes (and automation scripts, which use a java class to launch your script). For example, BMXCREWID is a condition that uses a java class to determine if it should evaluate to true/false.

Because of the substitution variables and java classes, it doesn't seem likely that it would evaluate the condition in report object structure scenarios. But when you're retrieving data from the REST API you're interacting with MBOs so it can easily evaluate the condition logic."

Do we have any other options for filtering object structures for the purpose of ad-hoc reports?

Thanks.

Hi Steven,

It looks like you were right. The "Data restriction condition" field (MAXINTOBJECT.RESTRICTWHERE) didn't work for ad-hoc reports (QBRs).

I added the BMXTKTNOTASK condition (:istask=0) to a custom report object structure . I used the report object structure in an ad-hoc report, but the report didn't exclude task records. So I think that tells us that "Data restriction condition" doesn't apply to ad-hoc reports.
 
"I don't think this would apply to QBRs (since you mentioned a report structure). I think this is purely for retrieval of data using the REST API since conditions can not always be converted to SQL."

"...conditions can be java classes (and automation scripts, which use a java class to launch your script). For example, BMXCREWID is a condition that uses a java class to determine if it should evaluate to true/false.

Because of the substitution variables and java classes, it doesn't seem likely that it would evaluate the condition in report object structure scenarios. But when you're retrieving data from the REST API you're interacting with MBOs so it can easily evaluate the condition logic."

Do we have any other options for filtering object structures for the purpose of ad-hoc reports?

Thanks.