Archive for August, 2007


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.


Just in case you are looking for VFP training and you are not on the Visionpace distribution list, here is a notification I received this evening:

The next VFP Boot Camp will be in Kansas City, Missouri, October 1-3, 2007

Registration ends on September 14, 2007 for the highly-acclaimed VFP Boot Camp. This event delivers three jam-packed days of solid, hands-on learning. From the fundamentals of VFP development through the very latest VFP 9.0 features, this boot camp is designed to quickly get your VFP skills up to speed. Attendees will receive a 500 page manual in both print and electronic format.

For more information visit or email info AT visionpace DOT com. To register call 888-904-7900



The initial session schedule for Southwest Fox is posted! Please note that the organizers have reviewed it and passed it by the speakers, but it is still subject to change if we discover a flaw. This will be finalized over the next couple of weeks.

You may be wondering how did I get two 8:00am sessions?!? You think I would have some pull being one of the organizers, but no, Tamar thinks I am good enough to keep people awake on Saturday and Sunday morning (at least this is what I am telling myself {g}). Seriously, I am not really complaining because I don’t mind the first session of the day.

I went through the schedule a few weeks back and picked the sessions I would like to attend (knowing darn well I might not get to any of them) and I only had one I could not schedule. There are definitely some tough choices, but that is the idea. We packed this conference with lots of great sessions presented by some of the best minds available.

I have two recommendations to those who cannot see all the sessions they really have to see. One thing I am doing is seeing sessions in advance of the conference. Check out the Fox user groups around the country kind enough to let speakers test-drive the sessions before they might be ready for prime-time at the conference. I see the Detroit Area Fox User Group (my local group) and the Chicago FUDG already have presentations scheduled. I am sure other groups will be scheduling some soon. You can find some of the user group meetings on the Fox Wiki Upcoming Events page.

The other option is to bring a teammate or friend to the conference (yes there is still time to register and we are not sold out yet {g}). You can each see different sessions and later go over the material you learned to help the other person as you review the white papers from the session together.

Only 50 days until we meet in Mesa!

, ,


I have a customer who is a developer using VFP 8 so we cannot use the new FLUSH FORCE functionality.

Here is the observation. Simple form with a private datasession opens the table and displays the data in the standard grid. The table is one of your typical USER tables and it has a logical flag in it to show if a user is logged in or not. The management like to occasionally check to see who is logged in or not. SET REFRESH is set to 10, 10 so every 10 seconds VFP should be refreshing the local buffers.

I can load up the app on my Windows 2003 server and the form performs as expected. As I start instances of the EXE and login as different users I can see the Flags change to true once the grid is refreshed or I move through the records after the 10 seconds.

If I run the EXE on a Windows XP SP2 machine and run multiple instances of the EXE on the same machine I do not get the data refreshed. I have even seen where I run the same form in the same EXE instance set up its own datasession with the old data.

Now I know the private datasessions are doing a USE AGAIN which does not go out to disk and get a fresh buffer, and uses the current cache to set up the new workarea. I also know if we throw in a simple RLOCK() it will refresh the cache.

It would be nice if all the installs were on a real server, but some of the end users are in a peer-to-peer environment and this is causing problems with the refreshing of the data.

My question is: is there something in Windows where we can turn off the data caching? I have hunted everywhere and I cannot find anything. I am recalling reading some where that Window 2003 has this shut off by default, but XP does not, but I cannot find the source of the material I read. Obviously Windows is caching the data or the Fox Team would not have added the FORCE clause for the FLUSH command.

The app cannot be migrated to VFP 9 to take advantage of the FLUSH FORCE. My recommendation to date is to use the RLOCK() “workaround”, but understandably if the developer has a toggle of a setting in Windows he would save himself the time of updating 50 forms, performing a complete system test, and the time it takes to redeploy to all his customer locations.

I would appreciate any insight any of you might have.

UPDATE 08-Aug-2007 @10:28 PM: passed along from fellow VFP MVP Fred Taylor on where to set the Windows Write Caching…

“If you mean the disk write caching, in XP bring up a My Computer and right-click on the disk you want, then choose properties. Then under the Hardwaretab, select the actual disk device and then use the Properties button. Under the Policies tab, there should be a check box for write disk caching there.”

I appreciate the help Fred!


One of my customers who is a developer described a form he built with the following scenario:

  1. Private Datasession, single DBF table
  2. Load event method opens the table and runs a SQL-Select of all the records into a cursor
  3. Display of the records in the cursor in a grid. Grid RecordSource is the name of the cursor.
  4. Observes the data change in the grid when users are changing the data in the base table on other machines in the office.
  5. There is not code to rerun the SQL-Select, and no timers on the form.

His question to me is: how the heck does this happen? Good question.

His assumption was that the cursor data was stagnant since he queried it from the base table into the temporary cursor. Initially I agreed with him and we both thought we were going crazy, but then I remembered something I observed many years ago.

When you perform a SQL-Select and the VFP data engine determines it can be Rushmore optimized, behind the scenes VFP creates a new workarea, which is the same as the open table in another workarea via the USE AGAIN, and applies a Rushmore optimized filter to the new workarea. In essence, the cursor is really passing through the raw table information in the grid he used to display the data. So changes made to the table by the other users in the system are reflected in the grid based in the settings of SET REFRESH.

At first we thought we were nuts, and I had to step through the debugger to ensure the grid was really bound to the cursor and not directly to the table.

One way to avoid this gotcha is to use the INTO CURSOR …. NOFILTER clause on the query. It will slow things down a bit since it is forcing the cursor to be written to disk, but you will not get the filtered table, you get a real stagnant cursor.

Hopefully you will remember this situation if you run into the weird and maybe unexpected behavior.


Kevin posted the tentative schedule for the FoxForward conference. Looks like a good schedule with three simultaneous sessions and several repeated sessions. No time better than today to tell Kevin you want to go to this conference and get registered.

Only 24 days until the conference kicks off in Hotlanta!



I was getting creative this evening with the VFP Session class. I was getting tired of changing the DataSession each time I created a private DataSession with the following code:

loSession = CREATEOBJECT("Session")SET DATASESSION TO (loSession.DataSessionId)

So I created a class in a program and added this code to the Init() of the Session class:


This does not work, the DataSession stays with the current DataSession. So I created a custom method in the Session class and called the method externally. Same result. Here is my test program:

LOCAL loSession as Session

?"--------------"?"Should be default DS 1: ", SET("Datasession")

loSession = CREATEOBJECT("Session")SET DATASESSION TO (loSession.DataSessionId)

?"Should be DS > 1: ", SET("Datasession")loSession = .NULL.

?"Should be default DS 1: ", SET("Datasession")

* Now work with a customized session classloSession2 = CREATEOBJECT("pssSession")?"Would think this would be DS > 1 after set in " +; "Init(): ",; SET("Datasession")

loSession3 = CREATEOBJECT("pssSession")loSession3.SetSession()?"Would think this would be DS > 1 after set in " +; "Init() and custom method: ",; SET("Datasession")

loSession2 = .NULL.loSession1 = .NULL.

?"Should be default DS 1: ", SET("Datasession")


*************************************DEFINE CLASS pssSession AS Session

DataSession = 2

PROCEDURE Init * Does not set the datasession to the * private DataSession, why? SET DATASESSION TO (this.DataSessionID)ENDPROC


PROCEDURE Error(nError, cMethod, nLine)ENDPROC

PROCEDURE SetSession * Does not set the datasession to the * private DataSession, why? SET DATASESSION TO (this.DataSessionID)ENDPROC


In my mind it should work and for some reason I could not explicitly understand why it does not. Then it hits me, the object is created in the current DataSession, thus when code returns from the Session object back to the calling program, VFP is automatically returning to the current DataSession. This is a common trap I see developers falling into when debugging code that is changing data in an object that was created in the VFP Default DataSession (DS 1). Not exactly the same thing, but very similar. Tonight I fell into the trap.

I proved this was the case by adding code in the Init and SetSession methods to display the current DataSession after the switch, and the DataSession is getting set in code, then reset when returning to the calling code.

Now I understand why I always use the following code when creating and moving to a private DataSession:

loSession = CREATEOBJECT("Session")SET DATASESSION TO (loSession.DataSessionId)

Maybe this will save you an hour of frustration down the line.
(edited to make sure code word-wrapped for visibility)


I am very happy to announce F1 Technologies is officially a Gold sponsor of Southwest Fox 2007, and is making a very generous offer to each and every registered attendee of Southwest Fox. Here is the official deal:

  1. All registered attendees of the SW Fox Conference that are not registered Visual FoxExpress users will receive a free copy of Visual FoxExpress including a 6 month subscription.
  2. All registered attendees of the SW Fox Conference that are registered Visual FoxExpress users will receive a 50% discount on a renewal of their Visual FoxExpress subscription.
  3. This offer is non-transferable and expires on 11/20/2007.

Wow. Mike and Toni have always been big supporters of the conference, and this is another fine example of F1 Technologies commitment to the Fox Community.

There is still some time and space available if you want to get registered. Only 66 days until we meet in Mesa!

Thanks Mike and Toni!

, ,