|
So you have decided to switch to SQL Server. It might be a wise idea to look for some solutions which will help introduce needed functionality into your FoxPro application. Take your time - we've already done it for you, and here's the result of our research:
Most solutions will need a completely rewritten code - it means, you will still have to rewrite thousands of lines. Mere Mortals Framework and CodeMine Framework are good products indeed, but they give you basic means you'll have to build your application on.
What is there to be done if you have already built your application and don't want to change its basics? Can we adapt a FoxPro application so that it could easily work with data stored in SQL Server databases?
Practice shows that we surely can. We should only take into consideration the following facts:
You will hardly want to switch from FoxPro tables to SQL so that your application would lose the ability of working with FoxPro tables and become able to work with SQL databases. Even if you plan to abandon FoxPro tables, the whole process will take much time and you will have to plan several stages of carrying it out; what's more important, you'll have to successfully implement these stages. Surely you can work with two parallel applications: one of them may be a FoxPro application working with FoxPro DBF, and a copy of this application working with SQL Server. But is it really the right way to develop and support two similar applications at the same time? We think it would be more appropriate to grant the existing application new functionality without influencing the existing one. Our goal was to ensure that the same application can work with data contained in ANY tables and databases (FoxPro tables, SQL Server, Oracle) and have direct access to DBF, ODBC, Automation, ADO, etc. In other words, such application can work with a set of objects and functions regardless of data types and transport types. The same application can work with the central SQL Server database in the central office of a company and with FoxPro tables (presented as materialized views containing sets of region-related data) in the regional offices of the same company. The product we describe here is actually built up from several basic elements of development framework. Its goal is to provide the developer with means of adapting an existing application to working with data in FoxPro tables as well as in SQL Server
database.
Troubles which you will face when trying to adapt your FoxPro application to SQL Server can roughly be divided into 2
groups:
1. Syntax. FoxPro syntax is very flexible while SQL standard is very strict. This results in having two different programming languages with different syntax. Only 1 % of your existing code will be correctly accepted and interpreted by SQLExec(). Our EasySQL4Fox library transforms FoxPro syntax to T-SQL
syntax.
2. A FoxPro application uses direct data access in many cases (LOCATE, SEEK, GO, BROWSE, ...), and this is not compatible with Client-Server technology. Our goal is to teach the application how to behave when direct access is allowed as well as when it is prohibited without changing the code of the existing application.
|
