re: "new big applications" -- I guess your pronouncement means that our 300+ table application would have been developed faster by developing directly on the backend. That's too bad: I thought our metric of 5 person-years to version 1 release was probably pretty good. I know for certain that if we had developed directly on the backend, we wouldn't have been selling the product for a year already.

It may well be choice of tools; we design in xCase, develop in a framework (VPM) that seamlessly switches to client-server, and integrate xCase and VPM with xCase2VPM. xCase, when we are done making things work with local tables (i.e., local views), generates the backend after being modified by xCase2VPM. At runtime, we can switch from local tables (views) to client-server (remote views) on a data-driven basis, by view. We save a ton of time by making it work locally, and converting only when the debugging has been done. That ton of time is the difference between profitability and not, at least for us.

Hank


>
>Hi Fabio,
>
>we have run into numerous issues where the SQL we generate works in MSSql, but does not work in Visual FoxPro. Getting the two to work as much as possible alike is of tremendous importance in getting Visual FoxPro acceptance in the marketplace, as it makes upsizing to MSSql a relatively easy task.
>
>Hank
>
>
>- For old applications this behavioure have little importance;
>- For new little applications, this behaviour have little importance;
>- For new big applications, a serious developer cannot implement it into VFP,
> but use directly a backend solid database.
>