>You might be right and I might do that for this specific form but I have a whole application (around 700 programs) writting using tables and relations, working since 4 years.

I can appreciate that; I was in a similar position. I used filtered tables, which work slow if combined with a grid.

Now, problems appear when the total number of records in the table becomes great. I decided to do some speed checks as soon as the table had more than 20,000 records. If it becomes too slow, I change a specific forms to parameterized views.

I suspect that you will also have the greatest speed tables in your largest tables. You could do some speed tests - on a single test form - and if you come to the conclusion that p-views are the ideal solution, you might gradually convert individual forms - starting with the ones that work with the largest tables, or simply where the users holler most.

Personally, I have never converted all my old forms to p-views - too much work. But for a new system, that is what I intend to use (for the child part).

>
>Now that the tables are filling up with more data these kind of "bugs" are showing up with more accruacy. To me it's either a VFP's bug or there is a parameters that I don't know. I see no reason that explain a grid would refresh in 2 seconds when there is data and it would take 2 minutes to find out that no record exist.

I assume you use either SET KEY, or a relation - both of which use the index. It might be a bug, in that the VFP team didn't give enough consideration to this special case.