Diffrences between LABTRANS.STARTDATE in Maximo 7.5 and 7.6

Body

Maximo SysAdm Times

Welcome to the Sysadm Times !!!!!!

LABTRANS.STARTDATE is non-persistent in Maximo 7.6

LABTRANS.STARTDATE field is not persistent in 7.6.0.1. Also the java class associated to this field is different, it's changed to psdi.app.labor.virtual.FldLabTransStartDateNP however in 7.5 it was psdi.app.labor.FldLabTransStartDate.

In 7.6.x　

Go to Database Configuration --> LABTRANS -->STARTDATE is non-persistent and the java class associated to this field is psdi.app.labor.virtual.FldLabTransStartDateNP　

In 7.5.x　

Go to Database Configuration --> LABTRANS -->STARTDATE is persistent and the java class associated to this field is psdi.app.labor.FldLabTransStartDate　

These changes were made during a design update for the Maximo 7.6.0.0 release. The goal of the update was to resolve ongoing customer pain related to lack of time zone conversions of datetime values. 　

Here is a summary of the changes made:　

The four datetime attributes in Maximo 7.5, STARTDATE, STARTTIME, FINISHDATE, FINISHTIME, were changed to nonpersistent. Each of the four database columns which used to be associated to these now non-persistent attributes is instead associated to one of four new persistent attributes, STARTDATEENTERED, STARTTIMEENTERED, FINISHDATEENTERED, FINISHTIMEENTERED. These classes behave as the old four attributes did when they were persistent. They write values to the same database columns which were written to before, STARTDATE, STARTTIME, FINISHDATE, FINISHTIME　

Objectives for this Enhancement:　

1. To enable time zone functionality when both the date and time are entered for the Start and/or Finish date　

2. To the best of our ability, to ensure as little disruption to clients as possible. 　

2a - by not changing the UI attribute name　

2b - by not changing the existing database column name 　

We also created two new persistent attributes, STARTDATETIME and FINISHDATETIME. When both date and time values are populated, the DATETIME database column will be populated in addition to the DATE and TIME columns. (This is where the timezone conversion problem is fixed: with both date and time values saved to the same column, we can perform the timezone calculation via the framework.)　

The new field validation classes for STARTDATE, STARTTIME, FINISHDATE, and FINISHTIME are simply extensions of the old field validation classes, to implement the functionality described above.

For example, FldLabTransStartDateNP extends FldLabTransStartDate (which is still present amongst your class files).　

Because neither database column names nor the names of the fields exposed in the UI were changed, we had hoped to avoid any upset to customer code. We can say that any classes which extend one of the original field validation classes should now extend the new field validation classes (i.e. extend FldLabTransStartDateNP instead of FldLabTransStartDate). And, any code you may have implemented to fix a timezone conversion error should now not be needed.