Hi Jim,

>First let me say that the "fast" applications that you worry about wouldn't "break", though you speculate that they might slow down to the point of unuseability.

What do you mean by "break"? I mean that the application is either slower, starts producing errors or behaves differently in a way that was not intended. It can certainly be slower, it would produce errors, for example, when disk space is not sufficient for results set of 1 GB size and it certainly would behave differently. For example:

Create Table Tmp (cField C(10))
Insert into Tmp Value ("Hello")
Select * from Tmp into Cursor curTmp
Select Tmp
Replace cField with "World"
? curTmp.cField && prints "World"

What if an application depends on the table and the SELECT result being in sync?

>What is still unclear to me is just how do you guarantee, in suchj apps, that a filtered result will be provided???

VFP follows certain rules when it creates a filtered result cursor. It won't create a filterd cursor one time, and a physical cursor another time.

>In addition, if (one of) the determinants of filtered vs cursor is the size of the result set, then is it not possible that the apps in question typically work with small results sets?

Why should they work on small result sets?

Christof