>Hi Craig,
>
>I am using a framework (VMP) and it seems to have a "hook" near the bottom of it's save method (more specifically, it's .UpdateBuffers() method for anyone using VMP) and it looks like somehow you can set something to force a flush on one or more tables but the documentation does not give a clue how to trigger this (it sort of looks unfinished - this is Drew Speedie's code). I will have to see if anyone knows how to trigger that.
>
>Having said that, I did not realize that there could be a lag between when data is written out to the buffers and it actually makes it to the tables - Drew does have notes saying this is under Windows control and thus why the FLUSH FORCE command was introduced.

Depending on if you're using NTier or not there are two ways to force table updates.
>
>What is also weird to me is understanding why the same user gets one results on the first run of the report and then if they run it immediately a second time, they pick up the new data - does the first one have VFP signal across the network that someone is accessing the table and then on the 2nd pass the table has been updated? It would have to be a flag in the table header that does this because remember from what I said below, the person running the report is not the person who has entered the data.
>
>Thanks,
>Albert

Before running a report you can call x3rlb on the tables involved in the query. That will virtually guarantee you get the latest data from other users. The default for VMP is to force table updates. Check the property ForceTableupdate in your xxconfig table.
>
>>Clicking Save and closing the form does not guarantee VFP buffers have been flushed. A starting place is to add FLUSH command every place data is saved (INSERT, UPDATE, DELETE). FLUSH will go after the actual data update statement.
>>
>>>My code does not have any FLUSHs in it. And in this case, the person running the report (the "salesperson") does not enter in the data - that is done by back office staff. The sales people like to run their reports throughout the day (particular at month end :-). But they are not entering the data.
>>>
>>>I am pretty sure that the person entering the data would have closed the form (and saved) much earlier in the day. Here was the example I tracked down today:
>>>
>>>- one sale entered with a timestamp of 12:01 pm (each record is timestamped when saved)
>>>- another sale had a timestamp of 1:02 pm
>>>
>>>When I logged in to run the report (at 1:30), I got both sales on the sales report
>>>
>>>- when the user who called ran it, he got neither sale showing up (I checked and he logged on at 11:15 am)
>>>- I had him run the report from another user's PC and they got one of the two sales; I checked and she had logged in at 12:36 pm
>>>
>>>So that makes sense - she got the sale that happened before she logged in but not the one after.
>>>
>>>I would have thought that there was something in VFP that when a query is run, it checks to see if there has been any changes to the table since the last time it opened it and if so, it refreshes its data.
>>>
>>>To me the weird part is that if the user runs the report again right away, they get all the data - it's like on a 2nd run VFP decides to pull down the latest data.
>>>
>>>Thoughts?
>>>
>>>Albert