Thanks Mike - great article by Andy.


>>Thanks Mike. I will stick with 5 then. And since you have used it successfully within the VMP framework, less possibility of me running into some "gotcha".
>
>Andy Kramek also recommends sticking with 5.
>
>"to us the answer is simple. you should always use table buffering with an optimistic locking strategy (i.e. buffer mode 5). the reason is simply that, with the exception of building an index, there is nothing you can do in any other mode that cannot be done in this mode. "
>
>http://weblogs.foxite.com/andykramek/2005/10/18/buffering-and-locking-in-visual-foxpro-an-overview/
>
>Dragan will remember that I have a special design where for example, my Invoice parent table can easily become a child table, because my design lets the user work flow decide, and does not force them to work a certain way. I can open a customer form and on it have an invoice button to show all the invoices for that customer. The user could theoretically update several invoices in a batch and either commit or discard the set of changes. Again that is mode 5.
>
>
>>
>>>>Hi Mike,
>>>>
>>>>I realize that this topic is old as we discussed it late last year. At the time I did a quick "fix" on some forms that I was having "data lag" problems on but did not address buffering across other forms. You pointed out (correctly) that in VMP if buffering is turned on, VMP code in .UpdateBuffers() does a FLUSH...FORCE on those tables (which cleared up the problems at that time).
>>>>
>>>>I did not change all my forms at the time (their main forms are based on frmDEGridNav2Pages) so the main table in these forms (.icMainAlias) which is a table, have buffering set to zero.
>>>>
>>>>Question: your response back to me said you set all your forms to 5 (optimistic table buffering). Is there a reason you used that over say 3 - row buffering? Or does it really matter? It seems that the gridNav2Pages only ever makes changes to one record at a time so I might have set it to 3. Do you know of a reason or is it just easier to set everything to 5 in case on some forms you are actually making changes to more than one record.
>>>>
>>>>I tested 3 and 5 and it seems to not make a difference. The other thought was whether it matters performance wise or not if it is 3 or 5 (does VFP somehow have to scan all rows for changes if it is a 5?).
>>>>
>>>>
>>>>Thanks,
>>>>Albert
>>>
>>>Hi Albert
>>>
>>>I try to program by exception. I want forms to be 5 unless I have a really strong need to change it. In the classic invoice+lineitems, the lineitems cursor on the details page would have to be 5. The invoice alias could be 3, but why? For that matter, I also do bulk imports, as part of the form. That also requires 5. So the real question is under what rare circumstance do I need 3?