The fun begins when there is a table in use. Your test was not the thing I meant, on my box I get almost the same results ( 24.8-24.9 for all). However starting with VFP7 it considerably slows down (to my surprise, why VFP throw away such a simple optimization). or not (I think first pass of loop was enough to make the distinction). Field variables gets precedence, so it checks fieldnames in current workarea and the memory variables (consults to and index called NTI).īefore VFP7 that check was optimized I guess, in a loop it didn't make a difference if you used m. VFP has to determine if you mean a memory variable or a field variable. Therefore in an assignment it is known that the variable is a "memory variable".
Microsoft visual foxpro 9.0 free download update#
It is not necessary because in VFP field assignments cannot be done with the "=" operator or store command ( a command like replace, update is needed). mix is a new variable name and should be used as m.mix,
Microsoft visual foxpro 9.0 free download code#
I would duplicate my project items (as a precaution as always - you may never remember that you introduced a new VFP9 specific code in new project) and give it a go under VFP9. As you can see almost all of them wouldn't be an issue for a "good style" code in VFP6. There might be other differences that I can't remember now. In VFP7 and later it slows down and the slow down might be dramatically noticable (not just few milliseconds, sometimes many seconds difference). Worked the same way (performance wise) whether there were an open table in current workarea or not in VFP6 (provided no field was named ix). prefix ) for memory variables is now not only needed for preventing ambigiouties but for performance in loops as well. The only noticable side effect you lose background colors in grid headers if any. You may turn the themes of or better yet utilize the new support for bitmaps in header with themes on. Visual themes support is new and on by default. They worked in VFP6 as "you" expected but was wrong. Calling other forms from valid (especially from within grids) should be prohibited. You can force the engine to work VFP6's way with the new global setting:īut the recommened way is to correct your SQLs. The bug in logic is obvious and VFP9 errors out. Select *, max(order_date) from orders group by cust_id Formerly it was possible to include non-aggregate columns even if they weren't specified in group by. Got closer to ANSI SQL 92. Corrected the "group by" bug existed in earlier versions (changed in VFP8). Here are the most common issues off the top of my head:
Each version came out with some differences (besides enhancements, new things) you should take care of but in general if the code VFP6 was written in a robust style already you may not need doing any changes. There is no documentation specifically created for "from 6 to 9".