Henry, It sounds like you have a problem similar to one I have. My script gets stuck looking for windows and screens that aren't there because the application/network connection got dropped temporarily. I asked the guys from BWS about it, and they suggested including a timeout or a call to a timeout script in each of the loops that's looking for something. Depending on the app, If you have a specific screen/window that should be open whenever the script is running, you could intersprerse your code with calls to a script to look for that window, and if not found, to restart the main script. Or if you know approximately how long the script should take based on the number/size of files/records to process, you could allow a generous timeout to restart the script after that time. Just some ideas I had. I wish you well with it.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Henry Hansen Sent: Thursday, March 30, 2006 5:03 PM To: [email protected] Subject: [Talk] How to build a robust script for Meditech --- best practices? Examples gratefully accepted! Hello, Generally speaking, my scripts work OK when conditions are good. It's when the "edge" cases of Meditech client instability, network link failures etc., come into play. I sure would appreciate reading about the strategies successful scripters use so they can sleep at night and know their scripts are printing things such as pharmacy MARs reports reliably every evening. Unfortunately, the network instability is something totally out of my control - as is the Meditech installation. (We are geographically about 300 miles away from our data centre hosting the Meditech servers). Overall, it's pretty good, but we'll see a few Citrix session drops a week, and a few times per day the 3 Tier Meditech client's startup/shutdown will take anywhere from .5 seconds to a few minutes, or completely freeze. Obviously I'd have a lot more hair if this situation improved ... but I still need to build some type of error recovery, and this environment seems like a real good place to perfect error recovery coding. My strategy so far has been to use a VB6 EXE and the three tier client for the added Boston Scripting functionality. MeditechCS connection BTW. When the time comes to run the report. Start the Meditech client. Set a timeut of a couple of minutes. Save the window handle. Set an on error goto Do normal script processing that generally works fairly well. Call Shutdown and exit. The error handler looks like this: ------------- ScriptError: Logit ("RunMedStan - Error handler: " & Err.Source & " " & Hex(Err.Number) & " " & Err.Description) If Err.Number = seDoEvents Then DoEvents: Resume Call ExitMeditech Logit ("Error handler finished.") The ExitMeditech sub looks like this: Sub ExitMeditech() Dim I As Integer If Active Then Logit ("ExitMeditech: Attempting to shutdown and exit.") Logit ("ExitMeditech: Sending 4 ESCs - waiting 1 second between each.") For I = 1 To 4 Key "{ESC}" Wait 1# Next Logit ("ExitMeditech: Sending 4 ESCs - waiting 0.25 second between each.") For I = 1 To 4 Key "{ESC}" Wait 0.25 Next Logit ("ExitMeditech - Connecting to non existant stream.") Connect "fred", stStream ' Close Boston Scripting Logit ("ExitMeditech - Setting Shutdown=True") Shutdown = True Wait 0.5 Logit ("ExitMeditech: Meditech client should be closed.") Logit ("ExitMeditech: Sending @_UNLOAD") Key "@_UNLOAD" Else Logit ("ExitMeditech: Meditech doesn't appear to be active.") End If ' ' If the Window is still hanging around. ' If IsWindow(meditech_hwnd) Then Logit ("ExitMeditech - hwnd still valid, killing process.") KillProcess (meditech_hwnd) End If End Sub Thanks, Henry Hansen @ Palliser Health
