I see. Although it's the same "Not Responding" message, Shipping Data Entry doesn't do an ODBC connection (not by default). Maybe the PU6 system is overall slower if not just slower in Shipping due to the SO consolidation feature. My own approaching to troubleshooting this could be something like:
* Make a copy of \mas90 for the PU6 system.
* Start the copy version so as not to disturb the Live users
* Duplicate the slowness in copy version then exit out.
* Rename \mas90\Links folder and try to duplicate slowness again. If speed OK, then then go down the road of mods.
* Run a SYZCON utility that forces an update of the physical tables from the dictionary, knowing the dictionary changed with PU4+ b/c of the Shipping / SO consolidation feature. Then test slowness again.
* Do a Program Trace on the start up of Shipping Data Entry to see where it bogs down
Also look for obvious differences. E.g. if PU2 shortcut used a mapped drive but PU6 uses UNC, try using mapped drive.
------------------------------
Alnoor Cassim
Free Agent Developer and Consultant
CallForHelp.biz
Email:
alnoor@callforhelp.bizOrange County, CA
------------------------------
Original Message:
Sent: 04-24-2019 14:21
From: Sue Bennett
Subject: ODBC Connection and Sage 2018 PU6
@Alnoor Cassim - we're just testing the ODBC Connection using the Start Menu/ODBC/SOTAMAS/Configure and testing it there. That's where using PU2 is instantaneous, but when we do the test on PU6, we get a "not responding" message and that's what is taking 4 to 5 minutes to load the files.
Where the client is being stalled is in Shipping Data Entry. The first time they go into Shipping Data Entry using PU6, they have to wait and endure the "not responding" message, which eventually clears, and from thereon they can use Shipping Data Entry with no problems. As long as they don't log out. If they log out and log back in, they have to wait the 4 to 5 minutes again.
We're sure it is all of the "new" things Sage has added in PU5 and PU6 with the new "consolidation of Sales Orders". We just don't know how to fix it!
------------------------------
Sue Bennett
Jack of All Trades, Master of 1
Bennett/Porter & Associates, Inc.
Tigard OR
503.620.3484
------------------------------
Original Message:
Sent: 04-24-2019 14:06
From: Alnoor Cassim
Subject: ODBC Connection and Sage 2018 PU6
Sue when you say ODBC connections where PU2 connects immediately but PU6 takes 3 minutes, are you referring to slowness for a specific Crystal report, Excel query, SQL Linked Server query, or Access query OR is it across the board slower ODBC? Also is there always a certain table involved like AR_InvoiceHistoryHeader ? I know with SQL and Access, I have to add ORDER BY InvoiceNo, HeaderSeqNo (the key fields) to the SELECT stmt to get the expected speed. Also, I had converted from 2018 PU1 to PU5 myself a few weeks ago and noticed several tables underwent conversion b/c of dictionary changes meaning if it's Crystal Reports you're talking about, you may need to Verify Database. Hope that helps.
------------------------------
Alnoor Cassim
Free Agent Developer and Consultant
CallForHelp.biz
Email: alnoor@callforhelp.biz
Orange County, CA
Original Message:
Sent: 04-24-2019 11:20
From: Sue Bennett
Subject: ODBC Connection and Sage 2018 PU6
PEP is set to "N" in both the PU2 and the PU6.
And @Jim Woodhead, it is Standard...but they're both on the same server with the same address...
Sue Bennett | President
P. 503 620 3484 | F. 503 620 2765
12559 SW 69th Ave | Tigard, OR 97223
Sue@benpor.com | www.benpor.com
Bennett/Porter Blog | facebook | twitter
Original Message------
one quick way to tell is to look for the email address info when you log into Sage 100 - if you see the job title/email address info. I think that is in indicator that PEP is turned on.
------------------------------
David Overholt
DWD Technology Group
------------------------------