Fix BMXAA7094E: The entered value 1.0 is not a valid integer

After upgrading a Maximo system to 7.6, Database Configuration can fail while creating an object with this message:

BMXAA7094E - The entered value 1.0 is not valid. Enter a valid integer value.

In this case, MAXSEQUENCE.MAXRESERVED had a default value of 1.0, although the attribute accepts an integer. Maximo rejected that decimal-form default when it tried to create the new object. Changing the default to 1 resolved the error.

Confirm the metadata mismatch before applying this fix. BMXAA7094E is a data-type validation message and can be raised for other attributes and values. Do not update MAXATTRIBUTE or MAXATTRIBUTECFG solely because the message text is similar.

Check the metadata

Ask a database administrator to run this read-only query against the Maximo database:

SELECT
  OBJECTNAME,
  ATTRIBUTENAME,
  MAXTYPE,
  DEFAULTVALUE
FROM
  MAXATTRIBUTE
WHERE
  OBJECTNAME = 'MAXSEQUENCE'
  AND ATTRIBUTENAME = 'MAXRESERVED';
 
SELECT
  OBJECTNAME,
  ATTRIBUTENAME,
  MAXTYPE,
  DEFAULTVALUE
FROM
  MAXATTRIBUTECFG
WHERE
  OBJECTNAME = 'MAXSEQUENCE'
  AND ATTRIBUTENAME = 'MAXRESERVED';

Continue only if both records exist, the attribute is an integer type, and one or both default values are 1.0. If the records disagree in another way, investigate that difference rather than overwriting it.

Preferred fix: Database Configuration

Where the field is editable in your release, correct it through Maximo:

1. Open Database Configuration and find the MAXSEQUENCE object.
2. Open its Attributes tab and select MAXRESERVED.
3. Change Default Value from 1.0 to 1 and save.
4. Apply the non-structural configuration change using the procedure for your Maximo release.
5. Sign out and back in, then confirm that the corrected value is active on every JVM.

A default-value change is metadata rather than a physical change to the column. Using Database Configuration keeps the active and configuration metadata synchronized and avoids an unsupported manual edit.

SQL fallback

Use direct SQL only when you cannot make the correction through Database Configuration. Take a database backup, test the change outside production, and stop or isolate Maximo application servers according to your change procedure.

Run both updates in one transaction so MAXATTRIBUTE and MAXATTRIBUTECFG cannot be left with different defaults:

UPDATE
  MAXATTRIBUTE
SET
  DEFAULTVALUE = '1'
WHERE
  OBJECTNAME = 'MAXSEQUENCE'
  AND ATTRIBUTENAME = 'MAXRESERVED'
  AND DEFAULTVALUE = '1.0';
 
UPDATE
  MAXATTRIBUTECFG
SET
  DEFAULTVALUE = '1'
WHERE
  OBJECTNAME = 'MAXSEQUENCE'
  AND ATTRIBUTENAME = 'MAXRESERVED'
  AND DEFAULTVALUE = '1.0';

The additional DEFAULTVALUE = '1.0' conditions stop the statements from replacing a value that has changed since your initial check. Inspect the affected-row counts and rerun the read-only queries before committing. The final state must contain 1 in both metadata tables; roll back if it does not.

After committing the SQL change, restart every Maximo JVM so the corrected metadata is reloaded. Retry the original Database Configuration operation and confirm that it no longer reports BMXAA7094E. Run the Integrity Checker as a final check that the active and configuration metadata agree.

This problem was observed after an upgrade to Maximo 7.6, although the exact release and test environment are unknown. Verify the records rather than treating the version alone as proof that this fix applies.

References

• IBM: Database Configuration
• IBM: Adding attributes to objects