Peter
> Nancy Folsom (PDI) wrote:
>> Keeping with the theme of "Best Practices" :), Jim Booth beat it into
>> my head years ago to use table buffering instead of row. You can
>> always _do_ updates for every row (I do that myself), but you're safe
>> from those unexpected times VFP changes the record pointer.
>>
>> I don't know why it's happening, and there can be any number of
>> reasons, but if you switch to table, update on every row change, you
>> shouldn't have any more trouble.
>
> Hi Nancy,
>
> Going to do that if I can't find out what is getting changed before the
> skip.
Do you have an expression in a textbox valid that is changing a field?
Are you're using IndexSeek anywhere? That actually moves the record
pointer tho' it moves it back.
You're not using row buffering for a cursor bound to a table, are you?
That is just not going to ever work well.
> Seems like a lot of trouble doing an update before any move to
> avoid this error.
Not really. I don't do it to avoid an error, it's just a more robust way
of doing row-level updates.
> Does this slow down your application noticably?
No. Since a table update is happening in either case. It's either
explicit (I call TableUpdate) or implicit (fox does it when the record
pointer changes).
> I have put some code in my form that will check the buffer and see if
> anything has changed by using GetFldState(-1) <> replicate("1",
> fcount()+1). I can then find out which field has changed and get the
> system to send me an email.
Did you put that in the error method? And, don't forget to wrap
GetFldState in NVL.
-
--
Nancy Folsom
Debugging Visual FoxPro Applications
http://www.hentzenwerke.com/catalog/debugvfp.htm
©2006 Nancy Folsom (PDI) |
