You know what they say – you are seldom assigned to a new role, instead new roles are constantly being assigned to you. This is how it came into past, that my job description (being the hospitable chap that it is) was kind enough to make room for yet another topic – second level support.

All in all, this suddenly made my job even more interesting. It is an established fact that no matter the data model’s flawlessness, no matter the excellence of design and no matter the software, be it rain or snow, given enough time and creativity, someone is bound to find an ingenious way of bringing that software to its knees. Thus it is with great confidence that I am promising plenty of new articles on how things can go wrong, and hopefully on how to fix them.

One common problem that I encountered so far is an issue that it’s usually pretty well covered during the first training modules – the difference between “Remove from Report” and “Remove from Grid”. Basically what happens is that users tend to play around with various attributes while creating a report and then neglect to properly remove them from the “Report Objects”.

Having an alien attribute in the “Report Objects” can cause cross joins, and the bad thing about cross joins is that, unless someone has a look at the SQL or the report runs into a spool space error then it is kind of hard to spot. I have seen user created reports that ran with cross joins for years without anyone ever raising an eyebrow…

It would be unfair not to mention that sometimes we need to bring an attribute to the “Report Objects” although we don’t want to see it in the grid, precisely in order to avoid cross joins. How’s that for confusing? Well, let’s just say that in this particular case, the attribute I’m talking about is not an alien attribute, but rather a “connecting” attribute. I can’t think of a suitable example, but feel free to post a comment if you have one.