>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.
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)