Thanks for the help, but I’m still baffled a bit. This data is telling me that all these drug files are pointing to non-existent patients, right? Sorry for the dumb questions, I’m not a programmer. By the way, I only have two test patients in the database and could blow all this away and reinstall if needed.

 

Matthew M. King, MD

Medical Director

Clinica Adelante, Inc

Surprise, Arizona 85374

[EMAIL PROTECTED]

 

-----Original Message-----
From: Gregory Woodhouse [mailto:[EMAIL PROTECTED]
Sent: Friday, June 09, 2006 1:19 PM
To: hardhats-members@lists.sourceforge.net
Subject: Re: [Hardhats-members] HELP!! Expert Order checking is out of order

 

 

On Jun 9, 2006, at 8:29 AM, Matthew King wrote:



 

Here is the output from the verify fields of file 55:

 

2708      2708                          No '2708' in pointed-to File

2710      2710                          No '2710' in pointed-to File

2711      2711                          No '2711' in pointed-to File

2712      2712                          No '2712' in pointed-to File

2714      2714                          No '2714' in pointed-to File

2715      2715                          No '2715' in pointed-to File

that continues for all the files except one is missing

 

 

I kind of thought that was the problem.

 

One thing that has always mystified (and annoyed) me is why VistA programmers take such a cavalier attitude to errors like this. I once did have a site report a problem with cascading errors and mail boxes filling up. Of course, I fixed it right away, and hope I never allow anything like that to happen again. 

 

I don't think I've ever seen anyone else do this, but my opinion about how to deal with errors is:

 

1. If you are dealing with any kind of unreliable resource (meaning any physical device, and certainly suspect data), ALWAYS define your own error handler.

2. When you encounter an error, create an error log entry (D ^%ZTER), clean up after yourself, unwind the error stack (D UNWIND^%ZTER), and go on.

3. If you encounter a problem in your own code, don't just wait for everything to come crashing down, raise an error (S $EC=",Uxxxx,"), handle it, and log the error in your handler.

4. If a process gets into a bad state, don't leave it there. Go back to some consistent state, and possibly QUIT.

 

We REALLY need to do a better job of error handling, including responding intelligently to catastrophic failures.

 

Gregory Woodhouse

 

Metaphors be with you.



 

_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members

Reply via email to