This mini-series outlines some risky practices that I have seen from Maximo and non-Maximo installations or heard about when talking to system administrators. Some examples will be from before I entered the Maximo world but they will all be applicable to Maximo systems.

Maximo is often used to help manage risks for work on highly valuable assets but ironically installations can have risky practices that put the Maximo installation at risk and this mini-series will highlight some of them.

Executing SQL statements directly from Java code

Executing SQL against the database is always risky and I have discussed it in this article. That was in the context of system administrators rather than a customisation

Developers can write code based customisations that bypass the MBO business rules and execute SQL directly.

This could be within automation scripts / Java code or even BIRT reports.

There are several dangers:

• Table structures & relationships can change between versions and sometimes between fix packs when a major change occurs
• Business rules can be broken/ignored
• Entries may not be traced using the standard loggers
• It can cause deadlocks on the database and record refresh errors

My advice

1. If you are accepting a release then ask if the code is executing SQL directly behind the scenes.
2. Ask why it wasn’t implemented using an approved method e.g. MBOsets
3. Write a set of guidelines for developers and ensure that any breaches of those are clearly documented and the reasons why
4. Avoid using this type of non-standard code
5. Vetasi offer consultancy to look for these types of problems and advise on how to remove/reduce the need for the code