by stecenko » Tue May 28, 2013 10:42 am
To my mind, the critical factor is whether your existing application is 'pure views'.
If you are using tables with indices and replaces, then all that has to be converted to views.
The issue then becomes this...
Is it easier to re-do your existing application so it uses views and then move the views to SQL
or
re-write your existing application in VPME 9.1.12 to use remote views?
But it's not really that simple. For example, are you using surrogate keys? If not, that adds a another complexity to using SQL especially if you have compound primary keys and especially if you have compound primary keys that include a date field.
There is nothing you used to do with tables that you can't do with SQL. But, if you are going to keep all the 'old-fashioned' ways of doing things when you convert to SQL, then why bother?
You have to examine your reasons for converting.
If you want performance, then you have to re-consider table design. A slow, bloated database is bloated whether it is in VFP or SQL.
If you want to share your database with a web-based application, then you also have to consider table design.
If you are going to re-design the database, then you are probably going to re-write. If that's the case, then re-do it in SQL and VPME 9.1.12 using remote views. You can copy/paste code, re-use reports.
Remember, VPME is a rapid-development tool. You'll probably find that 75% of your forms can be re-build with the builders without adding any code. And 25% of your reports can be made more elegant using VFP 9
It all depends on why you are converting.
Richard Stecenko
Interactive Computer Services Inc.
Victoria, British Columbia
204.453.2052