Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

slow response

Status
Not open for further replies.

rsymonds

MIS
Jul 25, 2008
90
0
0
US
I have some users that use specific screens more frequently than others as in a purchasing agent and the PO screens. They have long delay times waiting for the screens to open compared to other users. An example is the purchasing manager creates PO's all the time. When he launchs the screen he might have a 2 or 3 minute wait. The OE girl also has the same problem and they both claim it is getting worse.

My question - is there a cache file or something somewhere that needs to be maintained?
 
The OE and PO applications are two of the larger Macola executables. If the local PC has any realtime virus scanning software active, it's possible that the Macola applications are being scanned as they are opened. Most RTAV software allows you to configure files or folders to be excluded from a real-time scan.

A quick test is to disable any RTAV software temporarily and see if the applications open faster.

Peter Shirley
Macola Consultant, PA and surrounding states.
 
it is only slow on the user workstations that use that part of the app all the time.
 
Any Flex code or modified screens?

Software Sales, Training, Implementation and Support for Macola, eSynergy, and Crystal Reports

"What version of URGENT!!! are you using?
 
We had a similar situation and it took a while for us to figure out. We had moved our progression install to a new server. Months later, when we finally turned off the old server, users complained of slow loads of screens. It did affect only screens using Flex.

The final fix for us was to search the registry for references to the old server and delete them.
 
We have a very similar situation in which we migrated our Macola Progression install from one server to another. Now we have been running into long load times and login errors.

The main error we get is:

Error occurred during database connection:-2147217871

After saying "OK" to that message it hangs for a few seconds then says:

Invalid Name/Password combination!

You click "OK" to that one and 8/10 times it'll log you into the system.

I've tried what was suggest above and excluded the macola directory from our real time antivirus scanning, turned off tamper checking and deleted the references to the old server in the registry. But I'm still having the same issue.
 
Yes, we migrated all of the "data" databases as well as the screens db.

I've also checked the the users to make sure they have the correct permissions for each database.

In the same migration we also upgraded from SQL 2000 to SQL 2005.

We're currently running Progression 7.6.400a and Flex 7.6.300
 
And this is only occurring at login time correct? Once you are logged in there are no differences in performance from the prior version?

Software Sales, Training, Implementation and Support for Macola, Synergy, and Crystal Reports. Check out our Macola tools:
 
After the user is logged in there is still some significant slowness. We also use Goldmine and it's running against the same SQL server without any performance issues.
 
It looks like using Progression Explorer lets the user in when PWE doesn't. Explorer still seems to be slow opening modules but you're able to get into macola.

 
Exact show the same error (which is a SQL timeout expired error) for Visual Menu Builder. The recommended fix in this scenario is to shrink the log file for the SCREENS database (see Exact Portal document # 16.278.312).

If this addresses the problem, you may want to consider switching to simple recovery mode on the SCREENS database. I normally set the recovery mode on all Macola databases to simple and do away with the logs altogether but that is something you need to determine based on your individual requirements.

If shrinking the SCREENS log file doesn't address the problem try deleting the PWE generated workstation ODBC connections through the control panel. PWE will recreate these when you log in and it's possible these are holding some connection or setting that relates to your old server.

Peter Shirley
Macola Consultant, PA and surrounding states.
 
I had found that same document and tried shrinking the screens log file. The beginning file size was 2.5mb and the shrunk size was 1.5mb. Neither of these seems large to me but I maybe wrong.

I also tried deleting the ODBC connections but was unable to get the client logged in after numerous tries.

I then uninstalled macola and reinstalled it and I'm still experiencing the same issues.

I really appreciate the help on this, it's driving me crazy.

 
We're running SQL 2005, I just checked the SQL Native Client Configuration and we have both TCP/IP, Named Pipes and Shared Memory enabled. VIA is disabled.

The client is set to use TCP/IP to connect.

The clients are all using the SQL Server Client Network Utility that was installed off the SQL 2000 disk. Should we have been using something different now that we're running SQL2K5?
 
From what I can tell, the SQL 2005 client included some major changes to the ODBC DLL's so it probably couldn't hurt to install the SQL 2005 client and tools (not database) on a workstation and see if helps.

Also, any time there's a timeout error, you should look at the overall performance of the database and the database server. I see you mentioned that Goldmine is on the same server/database and it performs fine, so I would look at the Macola databases;

There should be a regular maintenance plan in place to optimize all of the Macola databases, data*, SCREENS etc. I did see online where SQL 2000 databases restored into or attached to SQL 2005 instances should be reindexed to provide the best performance so you may want to look at this - particularly on the SCREENS database, but possibly on all Macola databases.

As per my earlier post, review the need for database logging (simple recovery mode versus full).

Do you have this logged as a call with Exact?

Peter Shirley
Macola Consultant, PA and surrounding states.
 
I remember now why I was using the 2000 disc to do the install is because the 2005 discs where for 64bit so I wasn't able to install the connectivity tools from them on our 32bit workstations. I hunted around the microsoft site for a download but was unsuccessful (I'm not even sure this is a free download).

I think we may have found a good starting point. I just checked and there are currently no maintenance plans setup to run. We do transaction, differential and full backups daily but nothing as far as maintenance. I'm in the process of setting this up now.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top