tm1web.log error: Last AR data row object was null

[lotsaram]

I have a weird situation where a TM1 web application that was working perfectly until yesterday suddenly isn't.

The problematic websheet uses MDX to generate the rowset with a view that is null supressed. If a selection is made such that the MDX would produce an empty rowset then all is good as in the active form gets rebuilt but as expected there are no data rows. But the instant a "valid" rowset is generated the Tm1web session disconnects and the user gets a timeout message. Seems to be the web equivalent of your excel session suddenly crashing.

The error in the log is this:
ERROR Applix.TM1.Web.WebControls.Websheet.TM1WebFormula - Last AR data row object was null, check for off 'used range' reference

Anyone seen this before and know how to fix it?

[rmackenzie]

The error in the log is this:
ERROR Applix.TM1.Web.WebControls.Websheet.TM1WebFormula - Last AR data row object was null, check for off 'used range' reference

Anyone seen this before and know how to fix it?

I've seen this plenty of times and I suspect it is a bit of a red herring in that it is a fairly generic message in the stack trace of the exceptions thrown by TM1 Web and isn't useful for specific trouble-shooting. If your dev box is anything like mine then you'll find that if you search for this error then you'll probably find it popping up a lot.

Also, when I was following up this route of enquiry, I played around setting the 'used range' property of the sheet quite a lot to see if it made a difference, but it didn't. We went through a phase of websheet 'clean-up' (bad named ranges, unused formulas, unnecessary links to external workbooks, any VBA, overly complex conditional formatting, etc) which eventually seemed to cure a range of different issues...

The problematic websheet uses MDX to generate the rowset

Can you make a standard dynamic subset out of the MDX, in the dimension used by TM1RPTROW, just to make sure that it's not the underlying issue?

[lotsaram]

Thanks Robin (& James & Mark offline) for the comments. Yes the log is not very helpful, they seldom are.

We checked for invalid named ranges and the UsedRange property but that was all OK. The sheet in question uses a "helper" cube to control the rowset which is actually hidden and the body of what the user interacts with comes from another cube with a separate VIEW formula. For whatever reason there seems to be a "magic number" of around 300 rows after which the websheet not only fails to render but the client session gets terminated. Solution for now is to limit the number of rows being returned but implementing some pagination in the active form is probably the permanent fix.