By "browse the table from VFP" do you mean you can start another completely
 separate instance of VFP and verify that the data 
have been written there?

I am running my .exe and then browsing the table from VFP.

My first guess would be a pathing issue of some kind - do you have more than 1 
copy of the table/database in dfferent folders? Maybe the wrong one is getting updated.

My app uses full paths when opening databases and using tables and there is nothing else in the path anyway... good thought though.

Failing that, are you using any commercial framework? Is it possible that 
if you return to form A but don't explicitly call some sort of .Save() method, 
those values may be automagically reverted for you?

No commercial framework, no magic revert code anywhere. It really is as simple as I'm describing and it worked fine in VFP8... not much has changed in the app.

What is different between the dev and production environments? 
Are they on the same computer? What network, if any? Antivirus 
(server and workstation)? Any other system-level utilities in play? 
Same VFP9 SP level on dev and production? Workstation OS(s)?

Same computer for dev and exe testing. I've tested the exe on several different computers with the same result. Using local tables or network file shares, doesn't matter. Yes, same VFP9. Vista or XP, same result.


This is driving me absolutely ape****** . The inability to recreate the problem in development makes for very, very slow testing:
1. Change one thing.
2. Compile.
3. Copy.
4. Run.
5. Test.
6. If not fixed, repeat.

I just don't get how it could be there one second and then do anything else from Form A, close form, add another new record, doesn't matter, the old record gets reverted... without buffering.

I do have the table open multiple times using AGAIN. Wonder if there's a bug in VFP9 with using the same table multiple times with different ALIASES? Speaking of which, I HAVE seen some weird behavior relating to cached data on tables that are open multiple times.

So I went ahead and recompiled this in VFP8 and what do you know! Weird bug is gone! So now I have to figure out how to work around this VFP9 bug. Any ideas?