>Keeping the amount of data read from the backend restricted (to a minimum) often is the main worry in upsizing a xbase style vfp app.
>
>That said, with a generic searchform/a way to use the form as search parameter finder and some overwritable defaults (select those records changed by user up to n days before *his* last commited change if no filter is presented) you often reach a workable solution for most forms when switching over to views or cursoradapter.
>
>All in all, as long as the app already is already working on tablebuffering IMHO you have good chances to upsize without a total rewrite - if the app code is "worthwhile" at all.
>
>regards
>
thomas,

Greate reply, so, if I understand correctly, you are saying that if the application is already multi-layered in design with the proper handling of user interface design then you won't have to revisit those issues in too much depth?

That is my whole point, how many times have I seen the application using VFP local data present the user with a pageframe and on page 1 is a grid with all the customer records displayed for the user to choose the one they want. There is a search button to help them but the grid is there with all records in it. If that form came up with a search action as the center of the first page and no grid, then it is already designed for dealing with the large data bases that an upsized application needs to deal with.