>>Very good point, Jim. And a very good reason to do all current VFP development with upsizing in mind. View based applications, designed n-tier upsize very well. At this point, I think a strong case can be made that all new VFP development should be against a SQL (Express) backend. Definitely leaves more options for the future of both the app and the developer. A strong VFP app withe SQL data can be supplemented for web or tricky interface with .net modules or whatever. Best of both worlds.
>
>Charles,
>
>You are right on point. The biggest problem with upsizing, as I see it, is the mistaken idea that many developers have that it involves moving the tables from VFP to SQL Server or whatever when in fact everything from the way data is presented to the user to how the menu system works is up for review in an upsizing project.

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