At this stage, a consistency check of the RPD should also be run. During each iteration of OBIEE, the consistency check has become rather more strict, and more comprehensive in its validation rules. This means that any modeling in the 11g RPD that was incorrect/not in line with best practice may be highlighted. This may be flagged as a show-stopping error, which must be solved before the RPD can go live. For example, in 12c, the validation rules are rather more stringent about correct logical-column mappings. The naming rules are also stricter, so there cannot be leading or trailing spaces. Both of these issues will ag errors that will stop validation of a whole section of an RPD.

Other issues may produce warnings. These will not hinder deployment, but should ideally be resolved. An example of this is that the consistency check will now ag up a connection pool that is being used both for report queries and as an initialization block for variables. This is because it can create a potential problem with resource contention.

The key message is that an RPD upgrade should be run well in advance of a go-live date, to give a developer enough time to sort through any unforeseen issues.