Hi,

We have a problem with printing reports. If the user is a normal user any report takes ages to run. But as soon as the user is converted to a super user the sessions runs quickly. I presume its an authorisation problem.

so what authorisations are required to be set to get this corrected?

Thanks all in advance

BG

Hi


If it takes time and then shows the output of the report after a while, then I think it is not a authorization issue.

If authorizations are not set it would not generate the report at all.

It keeps going on forever. The last time, I was really patient with it and let it run for 30 mins! For the print period master (which will at the most have 200 records) this is just too much time. So the report is not really showing any output.

But after converting to super user. It is fine!!! :confused:

BG

Normal user authorizations are checked against a runtime authorization table and it may be that you have problems on that table. I would run that session with debug information (search the threads for DBSLOG) to try to get an idea on what is going on with that and where Baan is spending its time.

It might also be, that you have record/row level security on one of the tables involved. This will add some conditions to the where clause of the report and in unlucky cases an index oriented access becomes a full table scan.

A super user would have no such problem.

Hi


Please check ttaad4130m000, ttaad4131m000, ttaad4132m000, ttaad4133m000, ttaad4134m000, ttaad4135m000 --- If you have any autorizations conflict for the normal user.

I had the exact same problem at a customer, and it had to do with what Markus is referring. They had about 30 condition records into

ttaad4134m000 - Maintain table data authorizations.

The report ran forever for an ormal user...
If your problem is also related to this, the only solution is to convert them to superusers or try to put less conditions the table data authorizations. There are no miracles.

Fred

I checked the users. In fact cobverted him to super user and then made him normal user and gave him access to all modules in ti , tc, td, tf and tt.

Still not Luck!

I did a TT_SQL_TRACE = 0200. it seems to take forever while querying ttaad300 table! Does not make much sense. Actually thisenvironment is an archive company on a separate oracle instance. Could there be problems related to that? Or any other ideas ... any suggestions all welcome.

Thanks

BG

I would look at the table where the query is taking a long time (isn't ttaad300 the Maintain Printer Queue? This is stored on company 000). If this table contains huge ammounts of job information, can take ages - that's why we always had UNIX direct printing devices, no pdaemon's and less ttaad300 overhead.

If it's only printing, you should start looking at your pdaemon poling time or try to go for direct printing (search the threads).
If affects other sessions, then it may be a problem accessing the tt tables (too many authorizations within tt module?)

That doesn't make sense at first sight.

So are you saying that this problem ONLY occurs in the archive company?
And for clarification, does the report ever finish or do normal users hang indefinitely?

The only difference between an archive company and a regular company that I can think off is that the first may share some tables from another company. THAT company might require superuser status to do so.
Maybe ttaad300 is one of the shared tables (very possible).

Can you do an ORAPROF=0 and post the results?

Also, how about your tabledef6.1, db_resource and ora_storage/ora_storage2
files?

Dave