>The company I work for has a large, multi user, FoxPro 2.6 application. We need to move to a Client\Server environment, and we have always believed that was not possiable with our current application. (it makes extensive use of SCAN, LOCATE SEEK and other non SQL commands) However, I have been informed that there are ways to redirect table access to SQL Server that should allow the xBase commands to continue to work. An Access\VB programer I know showed me how he did this in access with linked MDBs. I know some VFP developers that say this can be done in VFP with views, but that it is slow for large tables (one of our clients had
>600,000+ records over a year ago...).
>
>Does anyone have any suggestions on moveing a 2.6 app to VFP and then making it Client\Server? I know a total rewrite is prefered, and we intend to do that, but a quick port would give us time to do the rewrite correctly.
>
>Any advice?
You're going to spend a tremendous amount of time on the port to VFP for UI and business services; I'd consider redesigning the app from the ground up, bringing in someone to mentor you in OOA/OOD and n-tier design, and make life easier for yourself by designing and implementing a 3 tier design at the start. If you're tremendously uncomfortable with the move away from the xBASE environment, do your data service layer with VFP, but use views, the DBC, and a well-defined interface for the data service layer; the net result becomes that you've isolated the changes to the app to the data service layer, and with a well-defined interface, you know exactly what needs to be offered when the shift to a backend product occurs - the interface remains the same, but the implementation details change; the interfaces and responsibilities of the data service layer remain the same when you move from VFP to another database server product.