We are having a problem with some reports freezing periodically, and I'm trying to get some advise on how to find the problem.

This happens with reports that will run just fine for several days, and then lock up for any user. The reports I’ve seen this happen with the deliveries table (tdsls045). I’m not sure if it is a database problem, or if it is because these are our most frequently run reports.

The report locks up right after the user selects the print device, but before they are returned to the session form. So all they see is a blank sttstpsplopen screen. The entire Baan client locks up: they can’t open other sessions or kill the current one.

I know there is a difference between a report being slow or locking at this point and after it gets back to the session form. If I see a delay after it has got back to the session form, I know that usually means the query is slow and I can tweak it to speed things up. I can also usually do other things in Baan. If it is slow or stops before it gets back to the form, something else is going on. I’m not sure what. Often, new reports have a little delay at this point the first time they run, so maybe it is some compilation thing.

Users can run other reports against the same table with no problem, often reports using very similar queries.

I can usually fix the problem by changing the query in this session and recompiling it. Usually I have to change the index used in the WHERE clause. My bandage solution is to have two versions of the query in the script, one commented out. When the problem happens I just switch the comments, recompile and we are good to go.

The problem doesn’t leave any errors in the BaanIVc4 logs, the SUSE Linux system logs, or the Oracle DB 12 logs (at least none I can find). I am wondering if there is some SET command I can use to help, maybe an TT_SQL_TRACE command or something.

Thanks.

You can try setting TT_SQL_TRACE to something like 200 - maybe it will show you what it is doing right before it locks up. This sounds more like something else going on with the system. I mean you should not have to switch queries to make it work. I assume you have Oracle since you said db 12 logs - do they see anything from the back end?

Not sure if this will help, but you could try running the Purge Device Queue session for the particular user.

This a 'under the hood' problem (at least in BAAN IV c3), not related to the session itself , so not sure if TRACE will give up anything. But worth the try. Could point to a Company 000 table.

Something else I just thought of - are they saving defaults in ttstpsplopen? I have had that cause me problems in the past. One of the first things I will do is delete user defaults for ttstpsplopen.

Do you regularly clean $BSE/tmp? I've seen such an effect (hanging ttsplopen) when there were *lots* of files. This happens because of the function tempnam() whicht has to check if the new generated file name does not already exist.

Regards
Günther

Thanks for all the suggestions. I'll try them next time this happens.

One thing I hadn't mentioned is that when this happens, the report locks up for all users. Nobody can use the report.

I do clean $BSE/tmp out regularly, but maybe not often enough. I'll improve that and, if this happens again, run a trace.