I believe that I have some work order labor transactions that have died and then risen from the grave to stalk me. I may need holy water or a chainsaw.
 
More accurately, I have two really old WO's that I was using for testing. I really want to close or cancel them as they mean nothing and shouldn't stick around anymore. When I try to either close or cancel it tells me that there are unposted or open labor transactions and that I need to run DC-D to find those transactions. DC-D shows nothing. This might have something to do with my investigating interfacing third party code with the labor tracking system in Evo. Of course, I have no idea where these zombie transactions might be though... If ever there was an argument for triggers and better database normalization!!!!

Ah yes, BKDCPLAB... I remember now. Yes, I did put a bunch of test records in there months ago and forgot all about them. So it was my fault (as I had assumed it was.)  
 
What irks me isn't that I did it but that evo was unable to tell me why it was failing. IT KNEW, OF COURSE, BECAUSE IT HAD TO HAVE CHECKED FOR THE PROBLEM. But did it tell me why it was failing? NO! Instead it made up some other lame excuse and lead me on a wild goose chase.  
 
Is it really so hard to write software that has verbose and correct error messages?
 
I suppose it at least had a text based error message. Nothing bothers me more than seeing the raw error code returned from a program. The stupid program knew what the error code meant, couldn't it have let me in on the secret? Microsoft is horrible at that. If I see another 80070005 error (that's access denied btw) or any of it's kin I will scream.
 
WHEW.... I feel better now.