>>>>>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.
>>>
>>>I'm not sure I understand. Why is that?
>>
>>See my other reply to Denis for further discussion. Mike, my point is that moving the data and dealing with the syntactical differences is ONLY part of the task in "upsizing" an application.
>
>OK. You discuss an application that was casually / poorly designed in the first place. Do you feel a well designed app with local data storage also needs extensive redesign when upsizing to a database such as SQL Server?

Not if it was designed with some thought as to whether the n-tier design would break if the backend were changed. But that proves Jim's point. (and I think you would agree) A good n-tier design means making the business layer and presentation layer pretty much data source agnostic. But it has been very hard to get a lot of Fox developers to see the need for that for the same reason that a lot of folks saw no need for a real framework (whether 3rd party or self-creating - assuming the creator had a clue) Even then, it is possible to write a theoretically n-tier app in VFE, Codebook, MM etc that still needs a lot of tweaking when going to sql.

But if the app was designed with remote views that avoided foxisms like views of views, minimized the size of recordsets coming over the wire (no GO TOP , GO BOTTOM browses <g> ), had parameter handling and didn't bind directly to data it is pretty much just an issue of converting local to remote views, using a connection handler and having a program that will massage and port existing fox data.