>>>>>>>Well, we may agree to disagree. I use cursors extensibly, especially in my webshop, and if all cursors were written to disk, the response time would increase drastically. One of the big advantages of cursors, is that they reside in memory if possible, and that is why they are so incredibly fast. If given a choice, I would choose the current behavior.
>>>>>>
>>>>>>Ho wait, here is some misunderstanding, as I see it. It is my finding that VFPs decission to use the disk is taken very quickly. In tests adding only some records was enough for this. And also you have no clue when exactly this will happen. If for your webshop speed caused by memory-usage is important, then you might be helped more by creating a ram-drive!
>>>>>
>>>>>AFAIK the amount of available RAM is important. My server has 2GB of RAM.
>>>>
>>>>Okay, so you're suggesting that the physical disk is not quickly used in YOUR case? Have you done tests to validate that assumption? How many records/bytes/cursors are required before you observe that a tempfile has been created?
>>>
>>>I never did any tests myself, but I have read some articles about this subject. I have also been to a lot of conferences, and have always heard that the algorithm VFP uses to decide when to use "real tables" in stead of RAM is very complex, and depends, among other factors, on the amount of RAM. But, I may very well be wrong. Anyway, for me the long field name problem which triggered this thread, has never caused any problems since I have always avoided unsafe techniques.
>>
>>What was the unsafe technique then?
>
>Well, using cursors with long field names, and then trying to change the strucure of this cursor, is one example...! In general, I would say that using long field names is a potential problem, unless you play 100% by the book, including the fine print, as in this case. The same goes for tables and directores with spaces in their names. Doable, but asking for problems. Another example is Index on alltrim().

Spaces in file names is a feature asked for by the (virtual) user. It makes interacting with applications more user friendly. Long field names ... same story. I'll never gonna tell other, new developers that they should avoid such features. On the contrary, long names and spaces are among the key features of modern applications.