The update is to the LaborDtl.AcriveTrans & LaborDtl_TimeStatus fields. The
table is big so the BAQ limits it to last & current day. If you’re thinking
of a dashboard for this, you could use the JobNumber.
The query syntax is:
select
[LaborDtl].[JobNum] as [LaborDtl_JobNum],
[LaborDtl].[EmployeeNum] as [LaborDtl_EmployeeNum],
[LaborDtl].[ActiveTrans] as [LaborDtl_ActiveTrans],
[LaborDtl].[TimeStatus] as [LaborDtl_TimeStatus],
[LaborDtl].[LaborHedSeq] as [LaborDtl_LaborHedSeq],
[LaborDtl].[LaborDtlSeq] as [LaborDtl_LaborDtlSeq],
[LaborDtl].[LaborType] as [LaborDtl_LaborType],
[LaborDtl].[CreatedBy] as [LaborDtl_CreatedBy],
[LaborDtl].[CreateDate] as [LaborDtl_CreateDate],
[LaborDtl].[CreateTime] as [LaborDtl_CreateTime],
[LaborDtl].[ChangedBy] as [LaborDtl_ChangedBy],
[LaborDtl].[ChangeDate] as [LaborDtl_ChangeDate],
[LaborDtl].[ChangeTime] as [LaborDtl_ChangeTime]
from Erp.LaborDtl as LaborDtl
where (LaborDtl.ChangeDate >= DATEADD (day, -1, GETDATE()))
This is a common problem with our system as well. Many times this will happen and we’ll see “Lock Wait Timeout” multiple times in the app server logs. This error is because of a deadlock in the SQL database caused by some sort of bug in Epicor that we can’t get pinned down for support because it only happens coincidentally on the floor. Waiting a few minutes for all the locks to expire is the only remedy. Rebooting the server works because it takes longer than that for it to come up, but it’s rather extreme. Keeping everybody’s hands off after killing all the clients also achieves this. However, there doesn’t seem to be a very easy method to resolve this issue.
Jim, we are on Progress DB, not SQL and this has never happened to us before but ours seems to stem from one particular job and one particular operation on that job. I have no clue “why” but it’s happened twice now during “ending activity” on the particular operation on the particular job. Any idea what could cause it?
Best regards
Mike Abell
IT Manager
Flexial Corporation
a company of BOA Group
1483 Gould Drive, Cookeville, TN 38506, USA
Take a look at this job and one that doesn’t have the problem that uses the same operation, if possible. What are the differences? I would look at the resources as well. Do you have more than one resource for the operation?
I have seen this before but it has been quite some time ago.
Progress
it’s happened twice now during “ending activity” on the particular operation on the particular job
Not exactly the same as your situation…
Just something similar that happened to me this spring - V8.03.409C / Progress.
Out of the blue certain operations where users couldn’t clock out
and a nasty side effect:
The bi file would start to grow continuously after a user would try to clock out of these labor records. Performance degraded for all users & if not corrected would eventually fill up the disk.
each night I ran the conversion programs
---- had to find the related process(es) in the task manager & kill those, reboot the server
------- and go back and verify labor records were inactive. sometimes rerunning the conversion program(s).
After about a week I was told by tech support it was a known issue on 8.03.409C and patching to 8.03.410 was the only fix. I was skeptical but… the patch actually worked in this case.
Is anyone else having an issue with the RDDs not migrating for Crystal Reports? First I thought Epicor was not migrating the report type base so I changed the type to Crystal. Unfortunately that did not nothing for the migration of RDDs . Some of the RDDs are still missing. It’s interesting how only the last RDD for the form migrated. Why the last and not the first?
