Kert: First off, if it works, and it performs as fast as you need it to, don't mess with it. That's good money after bad.
Second, just for your own education, you may want to learn more about the SQL commands in Visual FoxPro. SQL are more of set-oriented commands (telling the engine WHAT you want it to do) rather than the procedural Xbase commands (telling the ending HOW to do it). There are situations where it can be much more efficient to use SQL. Tamar has a book available from Hentzenwerke (http://www.hentzenwerke.com/catalog/tamingvfpsql.htm), and a couple of dynamite white papers on her website (like www.tomorrowssolutionsllc.com/Materials/SQL_VFP9.pdf). You could replace your logic with something along the lines of: UPDATE OrderLn ; SET mstrupcno= EDILN.MstrUpcNo , ; MstrUpcQty = EDILN.MstrUpcQty, ; MstrUpcPrc = EDILN.MstrUpcPrc ; FROM ; EDILN JOIN OrderLn ON (column names = column names...); JOIN OrderHDR ON (column names = column names...); JOIN EDIHDR ON (column names = columnnames...); WHERE (some conditions apply...) The entire process executes as a single line of code, and you don't have to concern yourself with switching work areas, having the right index selected, etc. On Fri, Apr 20, 2012 at 11:04 AM, Kurt Wendt <[email protected]> wrote: > Actually - I 1st started re-writing the code due to a data issue. But, > in the end - that 1st re-write was not working. Now - based upon > everyone bashing the "Legacy code" - I updated it to proper code levels > - like Scan. And, now I ran it - and it works fine and does Exactly what > it should do. Here's the new code: > > SELECT EDIHDR > SCAN > xCurrCUSTPO = CUSTPO > xCurrORDER = ORDER > SELECT OrderHdr > IF !SEEK('TARGE'+xCurrCUSTPO) > LOOP > ENDIF > SCAN REST FOR account+custpo+order = 'TARGE'+xCurrCUSTPO > xExistingOrder = Order > SELECT EDILN > SCAN FOR ORDER+STYLE+COLOR+STORE=xCurrORDER ; > AND !EMPTY(mstrupcno) > SELECT OrderLn > IF SEEK(xExistingOrder +EDILN.STYLE+; > EDILN.COLOR+EDILN.STORE) AND > EMPTY(mstrupcno) > REPLACE mstrupcno WITH EDILN.MstrUpcNo , ; > MstrUpcQty WITH EDILN.MstrUpcQty, ; > MstrUpcPrc WITH EDILN.MstrUpcPrc > ENDIF > ENDSCAN > ENDSCAN > ENDSCAN > > FYI - the main DBF's - OrderLn & OrderHdr are BIG ones - while EdiLn & > EdiHdr are small and Temp files... > > -K- > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Man-wai Chang > Sent: Friday, April 20, 2012 10:27 AM > > Re-writing a working procedure? Don't do it unless you found something > really wrong, e.g., performance. > You have to make sure nothing will be broken and go through all test > cases! > > The best solution is to use a good SQL statement to do everything, > finding out whether Rushmore can help! > > On Fri, Apr 20, 2012 at 6:20 PM, Kurt @ VR-FX <[email protected]> > wrote: >> Jeepers folks - I already said I was going to rewrite it - 10 > responses >> telling me the same thing is already Beating a Dead Horse by now! But > - >> if it makes you all feel better to keep on beating that Dead Horse - >> then just go ahead and keep doing it... > > -- > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/cacw6n4tsr7dr_vqdjbzqme7j4tpofnberkchdcomshkeekp...@mail.gmail.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
