I wanted to follow up on the issue of Flushing Windows Cache in VFP 8, and some resolution for my client who you may recall is another developer.
This has been a very frustrating experience because VFP 8 is fundamentally not working in all cases and hardware configurations as one would expect with SET REFRESH. The data refreshes fine when pulled from my server, has failed on the C-drive of my XP machine, and works fine when run on my external USB drive. My client can reliably get it to fail on his Windows 2003 Server. Sure we have a workaround with RLOCK(), but you have to wonder why VFP 8 works as expected in some cases and not in others, and what potential problems do we have if RLOCK() reduces performance, or the technique does not resolve 100% of the problem.
So I had my client recompile the test applet in VFP 9 to see if the problem is reproducible in VFP 9. I know Microsoft is not going to develop a fix for VFP 8, but with VFP 9 SP2 in beta we might still have a chance to get something resolved if it is broken. It is definitely easier to go to tech support with a VFP 9 problem. Mind you, at the beginning of this journey I instinctively mentioned to my client how Microsoft introduced the FORCE FLUSH and how this interacts with the Windows API to get the changes to disk, so maybe they saw a problem with the SET REFRESH and worked to solve this in VFP 9.
Sure enough, my client recompiled his test applet in VFP 9 and all is well with the SET REFRESH. The test applet is showing the changes to the table in the second instance of the application in all the test configurations. So the good news (at least in this case) VFP 9 is more stable and reliable than VFP 8.
I think the recompile in VFP 9 with a complete system test is the best route to go anyway. It is just FORCEing his hand (sorry for the intentional pun) to make the move a little sooner than he hoped for in the scope of his project.
