I concur. I have had the same thing happen. I think Meditech has even suggested it on an occasion or two.
-----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Hall Sent: Saturday, March 24, 2007 5:16 PM To: [EMAIL PROTECTED] Cc: Meditech-L (E-mail) Subject: RE: [MEDITECH-L] NPR Slowness with Fragments (depending oninitialreport) post 5.5 All I know is that in similar cases, if I re-code the problem report as a brand new report, from scratch, then it works OK...Whatever hidden left-over inefficient code gets solved if you code it from scratch. Might be a lot of work, but it does seem to take care of it. Gary Hall Clinical Applications Specialist Estes Park Medical Center Information Systems Department 970-577-4443 -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Herb Bromenshenkel Sent: Wednesday, March 21, 2007 10:34 AM To: [email protected] Subject: [MEDITECH-L] NPR Slowness with Fragments (depending on initialreport) post 5.5 We have the most bizarre issue since 5.5 update. We have two reports (both call the exact same fragment), both supply the exact same info for the select (verified by %Z.ddc) I run one report - the fragment runs fast (5 seconds) (this report is much more complex than the 2nd) I run the other report - easily a minute I can even hard code the fragment with the select (passing @urn from ADM) and run it by itself. Runs about 5 seconds. I use the "slow" report to run the hard coded fragment, it hits the fragment right away, but takes well over a minute to process it (even though the select is already coded). Other FYI: The fragment is pulling the patient's allergies using meditech's mar allergy routine: %PHA.MAR.allergies(patient,70,"",1,"",2) I called Meditech's NPR and since have opened a task. They said the slowness has been reported before but didn't have a solution. Has anyone else seen this issue? Any suggestions would be greatly appreciated. I just can't fathom why the same fragment (with hard coded selects) would run so much slower when called from one report versus another. Herb Bromenshenkel RPh/Clinical Analyst 1300 Anne Street NW Bemidji, MN 55601 Voice: 218-333-5527 Fax: 218-333-5889 [EMAIL PROTECTED] =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= To subscribe or unsubscribe to the meditech-l, visit MTUsers.COM. To check the status of the meditech-l, visit MTUsers.NET. For help, email [EMAIL PROTECTED] ______________________________________ meditech-l mailing list [email protected] http://mtusers.com/mailman/listinfo/meditech-l The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender of this communication immediately. =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= To subscribe or unsubscribe to the meditech-l, visit MTUsers.COM. To check the status of the meditech-l, visit MTUsers.NET. For help, email [EMAIL PROTECTED] ______________________________________ meditech-l mailing list [email protected] http://mtusers.com/mailman/listinfo/meditech-l =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= To subscribe or unsubscribe to the meditech-l, visit MTUsers.NET. To check the status of the meditech-l, visit MTUsers.NET. For help, email [EMAIL PROTECTED] Visit the MTUsers WikiPedia at MTUsers.NET/mwiki ______________________________________ meditech-l mailing list [email protected] http://mtusers.com/mailman/listinfo/meditech-l
