ISTech Support Forum

ISTech Support Forum
http://www.istechforum.com/YaBB.pl
Evo-ERP and DBA Classic >> Problem Reports - Repeatable >> DC-A - Long delay to clock out.
http://www.istechforum.com/YaBB.pl?num=1462284065

Message started by TGerak on 05/03/16 at 07:01:05

Title: DC-A - Long delay to clock out.
Post by TGerak on 05/03/16 at 07:01:05

We updated to the 2016.1 version over the weekend and installed patches. Now when our shop floor people try to clock out of a WO on the shop floor using DC-A, there is a significant lag waiting for the number of pieces field to populate. The version we're running is dated 3/22/16. I suspect it may be related to the number of records in our WOLABOR file. Can someone confirm that a large WOLABOR file can impact performance?

Title: Re: DC-A - Long delay to clock out.
Post by DawnS on 05/03/16 at 08:15:26

We have 350k+ records and do experience slowness - especially when everyone is trying to clock out for break at the same time. I have Work Orders archived down to 3 years but have WOLABOR records still in the table from the beginning of 2010. Not sure how that relates to your table size?

Title: Re: DC-A - Long delay to clock out.
Post by Kelloggs on 05/03/16 at 08:22:54

Archiving data by itself will not improve your I/O time.
You need to Re-index your work order tables. (BKUTC.RUN)

That makes a difference.

;)

Kelloggs

Title: Re: DC-A - Long delay to clock out.
Post by TGerak on 05/03/16 at 08:24:49

We have 5 years of WO records. Our WOLABOR has 180k records going back to 2002. We are now experiencing a complete hang up.. I'm considering a roll back to the prior version of the program, but am concerned about a selective rollback not populating all the required tables.

Title: Re: DC-A - Long delay to clock out.
Post by Lynn_Pantic on 05/03/16 at 08:25:13

DC-A is using the BKDCPLAB table so the size of WOLABOR is not a factor. If you have not archived Shift records from BKDCPLAB that could make a difference. And yes, reindexing after archiving is important.

Programming is looking into the scan logic within the program to make sure it is optimized.

Title: Re: DC-A - Long delay to clock out.
Post by TGerak on 05/03/16 at 08:31:33

Thank you. Refresh my memory, do I need everyone out of the system to archive and re-index?

Title: Re: DC-A - Long delay to clock out.
Post by Kelloggs on 05/03/16 at 08:44:56

Yes!!!, very important
and don't forget to backup.

have fun

:P

Kelloggs

Title: Re: DC-A - Long delay to clock out.
Post by TGerak on 05/03/16 at 08:46:56

It gets hard when we're running two shifts and people are clocked in nearly around the clock. The opportunities to kick everyone out are few and far between.

Thanks for the help.

Title: Re: DC-A - Long delay to clock out.
Post by Kelloggs on 05/03/16 at 08:53:31

I do it Sunday night, from home.
Enable remote access. TCP port 3389

:P

have fun

Kelloggs

Title: Re: DC-A - Long delay to clock out.
Post by DawnS on 05/03/16 at 09:05:23

Reindexing was completed with the Archive process (done once a year in February). Our BKDCPLAB table is empty at the end of EVERY day. I check it as I have to clear out invalid 'employee' records (0 employee from HH-F and 1/10/100 employee from DC-A .... our codes are 10XX). The delay is about 5 seconds during 'random' scanning, but can be 30+ seconds when everyone is scanning out for break at the same time.

Title: Re: DC-A - Long delay to clock out.
Post by Lynn_Pantic on 05/03/16 at 09:50:02

Programming is looking into it. Hope to have something to release soon.

Title: Re: DC-A - Long delay to clock out.
Post by Lynn_Pantic on 05/03/16 at 12:08:14

Even though DC-A is saving to BKDCPLAB it turns out it is doing a scan through WOLABOR to recalculate the quantity complete for the operation in question. It is an indexed search so it should not be taking a noticeable amount of time unless you have a large number of records on a single operation which may be Dawn's case as she is using a single work order for everybody to clock break time. If the Break Time work order is defined as a Status I (Indirect) which it should be, we can easily change the program to ignore the recalculation for status I WO. Tony, we need more details as to the particulars of your situation.

Title: Re: DC-A - Long delay to clock out.
Post by TGerak on 05/03/16 at 12:26:51

We have WO about 180k transactions since 2002 in our WOLABOR file. We've archived WO's but I guess the labor transactions don't get archived. The job that someone was trying to clock out of (with the lock up) was an WO for IDL inspection. It's a sequence that has about 7,600 records. Will I do any harm reverting to the prior version of the program until I can archive some data?

Title: Re: DC-A - Long delay to clock out.
Post by Lynn_Pantic on 05/03/16 at 13:37:26

Archiving WO clears the WOLABOR records assuming the work orders are closed so I don't know why you have so many old entries. We are changing the program not to do the scan for Status I work order which is what the generic "catch-all" work orders should be so once we get that released if you change the WO status for the generic WO, the delay should go away. Reverting to a prior program version is generally not a good idea because data file structures do change. If it is a prior patch but the same numbered version (2016.1) then it is OK because by definition data structures do not change within the same numbered version. Going back to 2015.1 or 2015.2 is not advised.

Title: Re: DC-A - Long delay to clock out.
Post by TGerak on 05/05/16 at 12:43:49

Is there an ETA on this program modification? We had all kinds of issues getting scheduling to run with the stranded clock-in records.

Title: Re: DC-A - Long delay to clock out.
Post by Lynn_Pantic on 05/05/16 at 15:02:24

Testing now, will try to get it uploaded yet today (Pacific time)

Title: Re: DC-A - Long delay to clock out.
Post by Lynn_Pantic on 05/06/16 at 09:45:41

Patch has been uploaded. "Generic" work orders for clocking break time and such should be Status I (Indirect) and the quantity complete check that was causing the delay is not done for Status I work orders.