SmartList module is slow to load after install of Process Logic

  • 4
  • Problem
  • Updated 3 years ago
  • Solved
Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members. The community moderator provided the following reason for archiving: Old

Our users each run a local copy of GP 10.  Users that do not have the Process Logic module installed are able to open up Smartlist within less than a minute.  Users that have Process Logic installed have to wait up to 5 minutes for the window to open when they launch smartlist.  Can this be looked at to find some possible resolution?  

GP 10 and Pro-Log 273 (but this problem has been seen in all versions of Pro-Log that we have had)

-Bryan
Photo of Bryan Moye

Bryan Moye

  • 182 Points 100 badge 2x thumb

Posted 4 years ago

  • 4
Photo of Marilyn Long

Marilyn Long

  • 132 Points 100 badge 2x thumb

We also have experienced a delay in opening Smartlist after installing most recent Process Logic build. We are running GP 2010. Marilyn Long

Photo of Pam Schulz

Pam Schulz

  • 240 Points 100 badge 2x thumb
Oh, yes,  I remember this one too.  Process Logic is running something that is linked to the Smartlist, so every time you open the Smartlist, it's running a process "behind the scenes", I don't remember exactly what it is, possibly updating a EDI history table??.  I think this is something that Boyer can fix now. We had our Dynamics GP tech turn it off, which greatly improved the speed of opening smartlist.  Dan@Boyer, let me know if you need assistance fixing this issue!

Thanks,
Pam
Photo of FAQ

FAQ, SPS FAQ

  • 9,340 Points 5k badge 2x thumb
As always, Pam is on top of this issue.  It is a problem in Process Logic that we first identified while creating the GP 2013 build.  Process Logic had created a custom smart list which uses a temporary table to hold all the work and history records for EDI documents.  With large databases (lots of documents) this is very slow.  It is not a usable smart list and should not have been there in the first place.  In many 1-off builds that were previously sent out to users this smart list entry was removed but it was never removed from the core product.  We have removed this from the GP 2013 builds and will be removing it from the GP 2010 build as well.  This will resolve the issue.
Photo of Suzanne

Suzanne

  • 62 Points
Is there a fix for GP 10?
Photo of FAQ

FAQ, SPS FAQ

  • 9,340 Points 5k badge 2x thumb

There is a fix.  We will remove this odd Smart List from the Process Logic dictionary.  When that change is done we will post on the FAQ that an update is available.

Photo of FAQ

FAQ, SPS FAQ

  • 9,340 Points 5k badge 2x thumb
I have removed the SmartList that creates and uses the massive temp table.  This will speed up the SmartList starting issue.  This will be build 383 so going forward any customer that updates their GP 2010 version will get this new build with the SmartList removed.  GP 2013 already had this issue resolved.
Photo of FAQ

FAQ, SPS FAQ

  • 9,340 Points 5k badge 2x thumb

Build 383 has been installed now at one customer site.  After installing it we brought up the SmartList and it opened right away as it should.  So the solution is in place and working for anyone who would like to move to build 383 and speed up their SmartList use.

Photo of Bryan Moye

Bryan Moye

  • 182 Points 100 badge 2x thumb
Dan,   Have you created an updated cnk file for GP10 that would resolve this slowness?
Photo of Steve Larson

Steve Larson

  • 70 Points
since their doesn't appear to be a GP10 fix for this, can you tell us what tables it is hitting so we can manually remove the data from the Process Logic tables?  My assumption is these:  

JEDI321

JEDI322

JEDI332

JEDI333

JEDI334

JSOP301

Photo of Mai Yang

Mai Yang, Partner

  • 200 Points 100 badge 2x thumb

Hi Steve,

The Process Logic SmartList pulls all of the data from the Open and Historical tables and pushes them into a temp table for EDI documents.  If you have a Test company database to work with, I would suggest restoring a recent backup of your production database into your Test company database and then you can manually remove the data.  It is pulling the data from the JEDI221 and JEDI321 tables but if you will be removing data from these tables, you would also remove data from their corresponding tables: JEDI222, JEDI322, JEDI223, JEDI323, JEDI224, and JEDI324.  Since the JEDI221, JEDI222, JEDI223, and JEDI224 tables are considered the Open tables, you will want to leave the data in them as they will contain new imports.  Also, it may be wise to restrict off of one of the Date fields in the Historical tables so you don't lose all of your historical imports.  The EDI_DateImport field in the JEDI321 table could be of use.

Photo of Bryan Moye

Bryan Moye

  • 182 Points 100 badge 2x thumb
Steve, 

If your idea works could you please let us know the steps you took to implement it. 

Thanks much. 
Photo of Steve Larson

Steve Larson

  • 70 Points
Bryan, 

Was going to go down the road of removing via sql, but we found old instructions from Howard on how to remove........smartlist launch went from 3 min to about 2 seconds......  Transactions>Sales>B2B Import Sales, Choose Radio button for Hist, then the DateRange allows you to select Before Date...then enter a date, redisplay....takes a while but can mark all....then delete.....did backup the files first......but we went from 100,000+ trans to 3,000+...made smartlist workable...and cleared other files....but dont be in a hurry...not speedy...but works.  

This conversation is no longer open for comments or replies.