Z.rw.fragment moves the entire temp file, making a copy, and then (when frag is finished) the temp file is moved back.
This is why a fragment causes such a performance penalty to a report that has a largish sort file. I highly suspect that the five second report has no temp sort file, or a very small one (like one record), and the five minute report has a Larger temp sort file. The solution is to SEG to the PHA directory, open prefixes to the PHA database and dictionaries, and run %PHA.MAR.allergies, then SEG back to the original directory and restore the prefixes. You have opened a task with the RW group. They are going to be in a bind to offer you a solution because they have some kind of semi-official position that fragments are the only approved way to cross applications. A creative solution would be for them to write you a Z or MIS utility that would fetch allergies, that would keep the Segment crossing and prefix opening and restoring code on the NPR Programmer's side of things. I doubt that this problem is due to the 5.5 update, unless your general response time has slowed and that has caused the performance sapping behavior of fragments to become more of an issue. Joe Cocuzzo Vice President NPR Services Iatric Systems, Inc. Phone/Fax: (978) 805-4115 Email: [EMAIL PROTECTED] Web: www.iatric.com -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Herb Bromenshenkel Sent: Wednesday, March 21, 2007 12:34 PM 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 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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
