Topic
  • 6 replies
  • Latest Post - ‏2013-07-09T12:57:29Z by SASHULL
Michalis91
Michalis91
13 Posts

Pinned topic Making a non persistent attribute persistent

‏2013-06-25T05:47:08Z |

Hello all,

 

We were trying to create a custom report for our enviroment and we had an issue. One of the attributes from which we are going to get our data is a non persistent value (i.e the long description). We would like to know if it is advisable to set that value to be persistent  and any implications that might have. Have anyone ever tried this? 

 

 

  • Demonic240
    Demonic240
    26 Posts

    Re: Making a non persistent attribute persistent

    ‏2013-06-25T12:26:59Z  

    If all you're wanting to do is add the Long Description to a report, then perhaps try the following:

     

    https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/IBM+Maximo+Asset+Management/page/Adding+Long+Description+Object

     

    I've set this up in my organization and it seems to be working fine.

  • SASHULL
    SASHULL
    393 Posts

    Re: Making a non persistent attribute persistent

    ‏2013-06-25T19:56:23Z  

    Some non persistent fields are stored elsewhere in the database, and you just need to pull them from the other table like the long description, others are not stored ever and are simply calculated at run time. Report engines like BIRT or Cognos execute direct SQL statements against the database and if you tried to use a non persistent it would simply fail. You can try to build some of the logic into the report itself but some calculations may be difficult.

  • Michalis91
    Michalis91
    13 Posts

    Re: Making a non persistent attribute persistent

    ‏2013-06-26T04:35:56Z  

    Thanks Demonic240 for your reply.We thought of ROS too and maybe that is  the first thing we are going to do. The second thing we thought is to create a new table where all the values we want will be stored and through a trigger at database copy the details from the other tables we want to the new one. The new table will be used only for reporting purposes and nothing more. The issue here is that we would like to know if getting a value that is define as not persistent on one table and setting it up as persistent to another table if it is going to create any issues.

  • SASHULL
    SASHULL
    393 Posts

    Re: Making a non persistent attribute persistent

    ‏2013-06-26T15:14:59Z  

    Thanks Demonic240 for your reply.We thought of ROS too and maybe that is  the first thing we are going to do. The second thing we thought is to create a new table where all the values we want will be stored and through a trigger at database copy the details from the other tables we want to the new one. The new table will be used only for reporting purposes and nothing more. The issue here is that we would like to know if getting a value that is define as not persistent on one table and setting it up as persistent to another table if it is going to create any issues.

    A ROS doesn't have access to non persistent attributes either (again, all it does is create a BIRT report for you) so you would have to join to the object that does store the data if you want to use it in a report.

    If you're doing a database trigger, it's clear you know where the source data is coming from (such as the LONGDESCRIPTION table) so why wouldn't you just join to that table? A database trigger wouldn't have access to any non persistent attribute (such as DESCRIPTION_LONGDESCRIPTION) so that means it has to be stored in the database somewhere for you to use the information. Storing data redundantly in a database is never recommended.

    Updated on 2013-06-26T15:15:57Z at 2013-06-26T15:15:57Z by SASHULL
  • Michalis91
    Michalis91
    13 Posts

    Re: Making a non persistent attribute persistent

    ‏2013-07-09T09:08:47Z  
    • SASHULL
    • ‏2013-06-26T15:14:59Z

    A ROS doesn't have access to non persistent attributes either (again, all it does is create a BIRT report for you) so you would have to join to the object that does store the data if you want to use it in a report.

    If you're doing a database trigger, it's clear you know where the source data is coming from (such as the LONGDESCRIPTION table) so why wouldn't you just join to that table? A database trigger wouldn't have access to any non persistent attribute (such as DESCRIPTION_LONGDESCRIPTION) so that means it has to be stored in the database somewhere for you to use the information. Storing data redundantly in a database is never recommended.

    By join i suppose you mean join the two table the longdescritpion table with the application table we want to use for our report. Can this cause any issue to the way our system works?

     

  • SASHULL
    SASHULL
    393 Posts

    Re: Making a non persistent attribute persistent

    ‏2013-07-09T12:57:29Z  

    By join i suppose you mean join the two table the longdescritpion table with the application table we want to use for our report. Can this cause any issue to the way our system works?

     

    If you're doing database joins in your query (I wouldn't recommend creating a view to do it) then you should be fine assuming that you utilize the proper join. Using Long Description as an example, you must join all parts of the primary key column sequence (LDOWNERTABLE, LDOWNERCOL, LDKEY) to ensure you have a 1:1 relationship. Some new users don't utilize the LDOWNERCOL and get burned because a table can have multiple long description records for various columns.

    Also, be sure that you use a LEFT OUTER JOIN as Long Descriptions aren't mandatory and INNER JOIN would only show you records that do have a long description. Below is an example for joining from Work Order to Long Description to get the Work Order's Long Description:

    FROM workorder

    LEFT OUTER JOIN longdescription ON ldownertable='WORKORDER' and ldownercol='DESCRIPTION' and ldkey=workorder.workorderid

    So long as you use the proper joins this shouldn't impact your system.