Hello all,
I have a very strange case: When a user runs the session tfcmg4120m000, the session takes around 7 minutes to display the initial options, but when I run the same session with another user the session runs perfect!
Both users are in the same company and the same vrc, also Superusers, and also I have deleted the user and created again, but the problem persist.
Anybody have faced this before?
thank you in advance!

Try removing user defaults for the slow user. He is probably assigned
to a batch that no longer exists...

Dave

Thank you Dave,
I suspected that also, but, how I remove the user defaults?

It's session: ttstpdeldeflt

Dave

Dave,
I have run the session, but the result is the same...
Any other idea?
Thank you

Just for fun, it might be a good idea to do a DBSLOG=01570 and
compare the parameters between the two users.

also you might want to look in the inf_users to see if they each
have their own DB user.. if they do - swap the DB users to see if
the problem is in the DB...

Dave

Hi,

just a guess, but maybe the difference between the two users is that one of the user is the "Super User for Payments".
Check it in session tfcmg0100m000 "Maintain CMG Parameters".

Juergen

Thanks Juergen,
The user is not the Superusers for payments, actually I have changed and the problem persist.
¿any other idea?
Thank you.

Hi Dave,
The format in the ora_users is:

user1:user1:encrypted password:baan

what user is the dba user?
the first user1 or de second user1?
Thank you in advance.

<baan user>:<db user>:<password>:<group user>

So swap <db user> between your 2 problematic users to see
if there is a change.

Also - do both users use command line access? sometimes network can
be an issue (for example, one connects via a WAN and one via the local LAN...)

Dave

Thanks dave,
I did the change and nothig happend. The problem remains.
On the other hand I have run the parameter DBSLOG=01570 and I have the output. Honestly I dont´n have a idea how to trace it.
Can you help me on this?
Thank you in advance.

I didn't realize that you were oracle.

If you do an ORAPROF=0 trace, it should show the query that's cauzing
you the problem.

Nothing wrong with the db_resource / env settings.

What porting set are you on? you're using 8.0.6 libraries to connect
to 9i.. I don't think that's supported.

Dave

Hello,
I have changed the superuser for payments and the session starts at normal time, but when I change again the superuser, the session hangs again.
any Idea why occur this?
Thanks

Not sure I follow you.

If you turn off superuser it hangs, and if you turn it on then it runs?

if so, then it doesn't do a specific query when you run in superuser mode.. that's pretty common in Baan...

You could probably find the bad query with an ORAPROF or you could see if there are any fixes for the session in the support site.

Dave

Hi Dave,
The situation presents in the following scenario:
I have a superuser (for example, diana). When this superuser runs the session tfcmg4120m000, the sesion takes an abnormal time to display the first record.
By the other hand
in the session tfcmg0100m000, exist a field named "superuser for payments". In that field I have another user, for example, user-100.

When I change the field "superuser for payments", to diana, for example, the session tfcmg0100m000 runs like a charm!

Obviously, set this field is wrong, because diana is not the superuser for payments, so when I restored the old value, and diana runs the session tfcmg4120m000, again, hangs.

Any clue?
thank you!

Then -- -set ORAPROF=0 will tell you.

Dave

Hi Dave,
I have run the ORAPROF = 0, and I already identified the query that it takes an usual amount of execution time. In the first look, I could say that, due to is a new user, it doesn´t have any transaction done. But, the fishy ting is I have doing a transaction with this user and finalized! So, anyway this user is still taking a lot of time to display the first recrod.

any other idea?
Thank you in advance.

I would check for the latest version(s) of the session that triggers the long-time query in case that there were improvements made to the queries used within. I would also check the query from the database side and the tables involved to make sure that I do not have a performance problem there.

Hi Dave,
I have run the ORAPROF = 0, and I already identified the query that it takes an usual amount of execution time. In the first look, I could say that, due to is a new user, it doesn´t have any transaction done. But, the fishy ting is I have doing a transaction with this user and finalized! So, anyway this user is still taking a lot of time to display the first recrod.

any other idea?
Thank you in advance.

I'm not sure exactly what you're talking about since i can't see the query. But we might be back at user defaults. Instead of deleting them, you may have to set them for this new user.

Try taking that user, picking a record and doing a set defaults and then save and exit.

Also, does that query get run for the user that is fast?

Dave

Thanks Victor.
In fact, I have verfied that we don´t have database performance. And the funny thing is that, other users are running normal! The same query runs for everyone that runs that session, hence no problem with the triggers.

Anyway, I appreciate your oppinion.

Victor & Dave
Is my pleassure inform you that this problem has been solved.
I have set the parameter -- -dbgres -keeplog -logfile resource.txt
and in the first line of resource.txt appeared a strange message:

Can´t change the process group (Actually I have posted another tread in the forum)

And, I have done a search of that message that appears me. And I realized that the message is related with the SO. Follow this, I verify the set up user at operating system level and, in the parameter "USER SHELL" I have put the ksh as shell.

Hopping more than Suspecting, that this is the problem I switched to sh, and the message not appear any more.

I check with the user and (with a prayer on my mind), and for my supprice, the session is running normal!

Changing this parameter was the solution? Honestly I don´t know, but it works for me.

I want to thank everyone who help me on track this problem, and I want to share this "solution" to all who have a similar trouble. Maybe they will find this helpful.

Thank you all.

Wait a second..

You changed the user from ksh to sh and that fixed the performance problem?!

That means that you had something set in your .profile (or elsewhere) that was cauzing the problem. But I can't imagine what that was..

Dave

Hi Dave,
Yes, it was. I know, sounds incredible, even for me!
In fact I plan to try reply the problem and follow the same path of possible solutions in order to find what the heck was the problem.

When I finished, I will also put a tread to inform to the board.

Mike

Interesting thread in that we have an identical problem with tfcmg1120m000 where I came to the conclusion that the session behaves differently based on the user logged in and I believe that the session checks each payment batch to see who has created the payment batch. Estevens as a user is extremely slow to open the session as this user has created the majority of payment batches on the system but if we make estevens super user for payments then it doesn't appear to look at the payment batches and goes straight into the session.

Sols 200993 and 201139 are suppoosed to fix this (note sols also contain object for tfcmg4120m000) but for some reason they didn't in our case. Spoke to support about this and they closed the case as we only have one user for payment batches and the easiest thing was simply to make estevens the super user. Note users that haven't raised any payment batches go straight into the session. Whether these two situations are related is questionable because the direct debit table tfcmg401 doesn't appear to have a user stored on it.

However the two situations are so similar that in my opinion they must be related.

Regards
Neal Matthews
IT Support Analyst
ATY Automotive & Industrial Components (UK) Ltd.

Hi Neal,
Actually, the same occured for us. And in fact, SSA suport, also recommend us to install a solution for "increase performance". We don´t take it that solution due to, others users are running normal! Also we, set the problematic user to Superuser for payments, and the session runs normal!

In our case was a little diferent due to the superuser of payments has to be another user.

Yesterday I make some test creating new users and see if they runs the session slow or normal. My conclusion is,

1.- Make sure the user have the shell ksh.
2.- Run the problematic session, and process one transaction and finalized it.
3.- Change the user shell to sh.
4.- Check again the problematic session, the session must run normal at this time.
5.- If you need it, change again the shell to ksh. (As far as I know, running ksh or sh, differs in the start up of IPC_BOOT service).

Regards

Thanks for the update. It looks like we have both found a way around the issue.

Cheers
Neal