We don't normally deploy new versions of our VFP based health care app until several service packs have been released for the version we are developing in. Unfortunately, the features and marketing hype that VFP v8 was the most stable version ever lulled us into moving to v8 sooner than planned, primarily to embrace XML for a large integration project. Needless to say, this is turning out to be a grave error on our part, as there are numerous problems with version 8 that should seriously be considered prior to deployment. Some of the issues are minor interface problems with listboxes and grids, while others could put you out of business.

Consider the REQUERY function, which has been a stable and reliable friend for many years. It seems that when using REQUERY in VFP8 with a parameterized remote view, the requery doesn't always actually refresh the view, particularly if you have the code =REFRESH(lcAlias). We have found that if you lose the "=", the situation improves to about 90% accuracy. We also have tried actually selecting the alias i.e.

SELECT (lcAlias)
REQUERY(lcAlias)

and this improves the situation further.

If you use code like:

IF REQUERY(lcAlias) < 1
ENDIF

the situation gets better, perhaps to 95%.

lnResult=REQUERY(lcAlias)

Improves the situation further. I don't about most of you, but I have come to rely on REQUERY() returning the proper results. 98% accuracy isn't enough. Moreover, while I certainly understand that "=REQUERY(lcAlias)" is not code that should be in production, a quick search in message boards and MS Knowledge Base shows that it is used extensively even in Microsoft code. The bottom line is this is a serious bug that will cripple developers using backend DB's like SQL 2000 if you are not extremely diligent.

Note that when using REQUERY(lcAlias) OR =REQUERY(lcAlias) OR lnResult=REQUERY(lcAlias), if you set the TRACE window OR Watch window open and step through the code, the bug won't actually show. Any wait state at all will prevent the bug from occurring, so don't try to reproduce it in the command window because it works fine 100% of the time if ANY wait state is introduced. We have also found that putting an ACTI SCREEN and outputting the parameter the view is based on to the screen also "knocks" REQUERY into shape.

Perhaps a UDF that reads

FUNCTION vRequery
PARAMETERS lcView
*-- Introcue a wait state to force REQUERY() to work properly
WAIT WINDOW NOWAIT
RETURN REQUERY( lcView)

might work since WAIT WINDOW has worked in similar situations. Ridiculous, absolutely, however, if developers out there are anything like us, you probably have a lot =REQUERY( lcAlias) in production. My advice, test the piss out of REQUERY before deploying using a remote backend to prevent major problems. Even it it works in some methods, it will likely fail in others.

If anyone out there has an SQL 2000 backend server and wants to reproduce these bugs with REQUERY(), don't hesitate to ask! The best way we have found to reproduce the problem is to have a grid with a read only cursor with a list of valid primary keys from an SQL table with a VFP remote view. Then in the right click code of the GRID, fire a method like:

PARAMETERS lnApptID
*-- blah, blah test make sure it is valid, etc.
*-- Assume that lnApptID is the ?lnApptID parameter in your remote view
*-- This requery will fail the most. Doesn't like the "="
=REQUERY( "ViewName" )
*-- This one will fail less than above.
REQUERY("ViewName")
*-- The situation improves dramatically when using this code
IF REQUERY("ViewName") <1
*-- Best results...only made it fail a few times.
lnResult=REQUERY("ViewName")

The definition of "fail" is that the requery simply doesn't appear to do anything. If you have an empty view before, you will have an empty view after. If you have a view with data from a previous requery(), it will still be there after you requery with a different id. IOW, nothing changes.

I hope that this helps save someone from major heartaches. While I am sure that there is a workaround (there always is, isn't there), the old faithful "REQUERY()" is gone in VFP 8.

FWIW!