GP Login taking too long

(1) Share

Report

Posted on by Romryan

All,

My clients GP is taking long after the user enters the password until he/she sees home page.This takes like 30 minutes . 6557.gp.png

Its version 11.00.1524 (GP 2010).

After home page its ok.

Any idea on what I should do?.

RomRyan

*This post is locked for comments

I have the same question (0)

All responses (24)

Answers (4)

Bill Campbell 12 on at

Like (0)

Report

Just wondering, once open, how does the system respond?

Can you send details about the workstation - properties.

Is this a Fat or Thin client? Is this one and only one user?

Need more details, but we can help.

Was this reply helpful? Yes No
Verified answer

Redbeard 12,931 on at

Like (2)

Report

Try these queries - the first one will diagnose if you have the problem I think you do, and the next will resolve the problem. If the first query produces thousands of records, then you have the problem. Deleting these records is a safe way to fix the problem.

select * FROM DYNAMICS.dbo.SY07110 WHERE CmdDictID = 6499

--DELETE FROM DYNAMICS.dbo.SY07110 WHERE CmdDictID = 6499

Was this reply helpful? Yes No
Verified answer

Redbeard 12,931 on at

Like (0)

Report

I was able to find the following post from Dave Musgrave explaining the issue I believe you are encountering, why it happens and why the fix above works. I hope this indeed your problem, and the solution resolves the issue.

blogs.msdn.com/.../login-performance-issue-for-microsoft-dynamics-gp-10-0-sp5-and-gp-2010-sp1.aspx

Was this reply helpful? Yes No
Verified answer

coquisalsa 2,725 on at

Like (2)

Report

Hi Romryan,

I agree with Harry, while there are several things to examine, one of them is the number of rows in the Menu Master table (SY07110) which is a Dynamics System table.

This script will help you to find the number of rows in the table:

SELECT COUNT(*) FROM DYNAMICS.dbo.SY07110

This table is read whenever a user login and out of Dynamics GP, therefore the bigger the table the longer it will take. The standard number of rows should be around 1,500.

After a number of uses, the dropping of users and problems (bugs) with GP Products (Microsoft and 3rd party), this table can become very large and slow down the login process.

Drop all of the records in the SY07110 table, but before that do a table backup.

SELECT * INTO DYNAMICS.dbo.SY07110Backup FROM DYNAMICS.dbo.SY07110

DELETE FROM DYNAMICS.dbo.SY07110

GP will rebuild the table on the next login for each user.

I had two clients who had the same problem you are describing, one of them had 70,000 rows in the table! I fixed the performance issue by simply deleting all records from SY07110

Was this reply helpful? Yes No
Romryan on at

Like (1)

Report

thanks so much,Harry and Jorge you guys killed it.

Was this reply helpful? Yes No
kdraper on at

Like (0)

Report

Hmmm... I think I may have a different issue. When I run your query I only get 2 records. I have a total of 1,233 records in the SY07110. Both the classic and web client are very slow to login.

Was this reply helpful? Yes No
Community Member on at

Like (1)

Report

There are actually two parts to this login speed issue I'm finding and suggestions all over the internet for both inaccurately assume one issue with one resolve.

There is the splash screen with the application title, followed immediately by the login screen.

We have to wait for the login screen to accept a user name and password upwards to 2.5 minutes. Meaning it loads, and it is frozen before a user can select any field to provide their login creds.

Following that is the company chooser screen. For us, this moves almost instantly after the user is authenticated then we wait ~actually less time to build the home screen than the initial login freeze <1 minute. All suggestions regarding report library file proximity, auto pop list suggestions cleanup, user perms, duplication of shortcuts on load in Quicklinks and the customary SY07110 fix etc all really fall here.

So for the first part of this which is our problem -

The login screen hasn't authenticated a user name and password to GP at the time it runs and freezes so I don't see how SQL traces can reveal how GP application configuration impacts this? After running several traces with general user and admin logins and producing no meaningful results until after authentication, it seems to demonstrate that our issue is more application layer and less DB. I have exhausted all manner of suggestions regarding .NET framework tweaks and updates to policy and registry changes. Nothing impacts or even changes in any way the duration of wait to log in.

Is this your issue?

Was this reply helpful? Yes No
Verified answer

Redbeard 12,931 on at

Like (0)

Report

Kerry/MB -

Your symptoms are different than the ones Romryan reported. The SY07110 fix only applies to a narrow GP code base. So, you folks are in the unenviable position of working on problems this solution will not fix.

Were I you, I would start with troubleshooting 101. I do not mean to sound trite, but does GP behave the same way for all users on all machines? Just the answer to that question will speak volumes to potential problems and solutions.

If a user with full administrative permissions on the machine/domain, no User Account Control limitations, starting GP with elevated privileges experiences the same 2.5 minute delay between clicking on the GP icon and being able to enter credentials, this is not normal (obviously). If this is happening at every machine (or at the terminal server used by every user), then there is a systemic problem.

GP is Client/Server software, and prior to entering in credentials and authenticating to SQL, GP is simply a program, installed on a machine, which should not take 2.5 minutes to load. Since the GP Startup can reach out to server-side resources (i.e. reports and forms dictionaries), the network, user access, quality of these dictionaries cannot be completely ignored, but pointing to local dictionaries during startup, by changing the dynamics.set file (and recreating local copies of any server-side resources) should eliminate this vector.

If permissions problems and server resource causes are eliminated from consideration, using this methodology, then you're down to workstation based troubleshooting. Once you’ve eliminated these potential causes, please update your post.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Thanks for the reply.

I didn't elaborate in previous post due to its length already however systemically I have tested and verified ...

- Running as Administrator produced no different results than any user.

- All users experience same on first time login in am or any subsequent time of the day.

- All Libraries (.dic files) are local within the same folder and all .exe and config.

- Folder (and subs) are exempt from virus / malware scanning and execution blocking

- Performance monitors reveal unremarkable levels regardless of user location and time of day

- Disabled Generate Publisher Evidence in Dynamics.exe.config (old fix from older versions of .net framework known to resolve this)

Was this reply helpful? Yes No
Mike Bufano 1,484 on at

Like (0)

Report

Performance issues are never a fun thing to track down. Would you mind sharing your Dex.ini and Dynamics.set file?

Also, do you have the client installed on the SQL server? Does it perform the same from the server?

Lastly, are you in a WAN environment?

Are the workstation(s) and the database server in different domains that are trusted?

Was this reply helpful? Yes No