I wonder if this has anything to do with this http://www.istechforum.com/YaBB.pl?num=1210689094. In their case they got a start time entered but could never enter the end time because the record seems eternally locked.
 
Is there a wide spread problem with the labor entry? Is anyone on this list currently successfully entering in labor with the current version of Evo?

Collin,  
 
I understand what you are saying.  Most of the time the crew at EVO are very responsive and helpful, but every now and then, problems seem unaddressed (no doubt at times they are buried in issues or whines from us users.  On this one, I would just like to know a way to free up this employee.  The one option I have (if it would even work) would be to delete the employee and reenter him.

Mike,
 
That worked.  Thanks much!!

I was just about to send a message on this myself.  We have approximately 65+ people entering labor and this is happens to about 6 to 10 people each day.  Most time we can use the F9 key to flush, but sometimes we have to restart the server to clear.  Unfortunately, this does not work every time and I had to go into the BKDCTLAB file and delete the employee record.  However, it is happening so much, it is becoming a butt pain. As best as I can ascertain, this is happening mostly since release 03/27/08.
 
Dennis

We are trying to resolve this one but since it is so sporadic, while it is certainly a problem, it is not one we can programatically repeat and identify.  I suggested to Karen at Bula Forge that they try using the HH version of enter Labor/Production for a while to see if that version is better behaved, since it is a true GUI version compiled in the Evo compiler.  If anybody else can try that and report back if it is better, it would be helpful.

We just updated from 9/07 to 8/4/8 and immediately after the update began experiencing this problem.  At one point this morning, I looked at the contents of BKDCTLAB, and every user that was listed in there was getting the error "Someone is already entering transactions for this employee number" (6 users).  I got them into DC-A by using F9 to flush, but it's happening several times a day.

Thanks Lynn.  Yesterday I installed what you sent, and we made it through the whole day today with no more lockups.  Looking forward to the final patch for this, as we stopped using the barcode scanner about a year ago because of the three digit issue.

FYI - We still sometimes have to use F9 - not nearly as often - but it has not completely gone away. (maybe one or two instances per week)

Actually, now it seems to happen every morning, and F9 only clears the problem sometimes.  When F9 doesn't work, we end up with a rogue Work Order on the opening DC-A screen, with no assigned employee number:
 

 
And the record is found in BKDCTLAB.B03 with no assigned employee number (screenshot is wrapped):

 
Once I delete the record in Maintain DB, the employee is no longer locked out.  This is becoming a real nuisance.

FYI, when we have this issue all we need to do is close down evo (not the computer, just the program) on the data ccollection terminal and re-open the program. This frees up the program. It happens to us about once per day. I have looked in the BKDCTLAB file when this happens and there are no entires with no employee number.

Many times, we find that the lockup will occur if the DC-A screen is open and idle at one or more workstations.  For instance, on workstations A and B, the DC-A screen is open, but no one is using it (i.e. employee field is blank).  At workstation C, the message "BKDCPLAB is locked by another user" comes up.  When I check the Pervasive monitor, the Record Lock Type on A and/or B for file BKDCPLAB is Single instead of Normal.  Closing the DC-A screen on A and/or B will unlock C and they can proceed.

Have you tried the latest T7DCA, it is in the update. This, from the feed back we have received so far, seems to solve the locking problems in DC-A.
 
 
 

In the 12/21 update there is a new T7DCA for Evo only.  It has no record locking issues in it, at least none that  we have encountered. Also being tested and soon to be released will be the ability to post Parts or Parts and Labor automatically in DCA, and a new Internal rework operation.
 
 

Answers to Lynns questions
 
1.  Does the locking occur never/extremely seldom or occasionally (couple of times/week) or frequently (several times/day)?  
It locks 1 or 2 times a week, it depends if the employee leaves the transaction "continue entering for this employee" open or an error message appears and they do not close it.
 
2.  How many DC stations are being used?  
Qty of workstations 5
 
3.  If more than one, are they being used simultaneously when locking occurs?  
 
Yes.
 
4.  Do you allow employees to clock in/out of multiple jobs?  Yes
 
5.  Do you use Shift Start/Stop?  
Yes
 
6.  Have you noticed ANY kind of pattern?  
 
We have noticed that the problem seems to record lock when one of our users does not answer the question "continuing entering for this employee"   Our barcode scaners automatically answer this question for the user and it has reduced this problem.  
Since the barcode scanners are working properly now, (Updated to work with the new DC-A program) I don’t see a problem because it is automatically entered. It was an issue when employees are keying it by hand, because they don’t stop and READ it carefully…
 
7.  If you get a lock, Open BKDCTLAB with maintain database and see if you have a record with NO Employee number..  
 
           We used to have this issue, but it was corrected.