We have this situation as well. We have worked around where it happens by manually calling setfldstate on the problematic fields. In our case, there are only a few spots that it happens in and it is fairly consistent, so it is easy to detect and work around. Our application started in VFP5, and I think it happened there as well.

I'd never found any MSKB articles about it before now -- thanks for the link, even if it really isn't fixed.


>Hi all,
>
>I came across what appears to be an old VFP3 bug that was fixed in VFP5 bug has reappeared in VFP6, although slightly different.
>
>The old bug is:
>http://support.microsoft.com/support/kb/articles/Q163/0/29.asp
>
>The setup is this: I have a view on a table. In the view (not the table), I set a default value using DBSETPROP(). I open the view in buffering mode. If I APPEND BLANK, the default value is set correctly. Issuing a TABLEUPDATE() returns no error, and if I go check in the table, the new record is added correctly, including the default value set in the view definition.
>
>Now, instead of APPEND BLANK, I issue an INSERT INTO .... BROWSEing the view shows that the default value was inserted, the TABLEUPDATE() still returns no error, and back to the table, I can see that the new record was added, but the view's default value was ignored.
>
>This was working fine in VFP5. The program is being updated to VFP6SP4, but we're running into that problem. The problem was reproduced on VFP6SP4 French/Windows 98 French and on VFP6SP4 English/WindowsNT4 Workstation French.
>
>I would like to know: can anyone else reproduce the problem? Can those with VFP7 check if the latest version has the same problem (if that does not cause a problem with NDAs)?
>
>To those working at Microsoft: any chance for a fix? :)
>
>Thanks!