Rewriting a VFP 9 application into a web based application

woodwyn used Ask the Experts™
I have a fairly extensive  VFP 9 application that runs on a SQL backend with a lot of stored procedures.  There are basically three classes of forms in the application.  The first class uses an old third party tool, QBF Builder, for a three tab form approach to managing more static data like employees, clients, etc. (Tab 1 - Enter search criteria.  Tab 2 - View a list of results based on search criteria.  Tab 3 - Modify record selected in tab 2 or create a new record.)   The second class of forms is for data entry of work orders, time and materials, etc.  The third class of forms is to enter parameters used to build data for reports.  There is a lot of coding behind all this and it will take some time to recreate it.  Clients want the same functionality of the app available online and an eventual complete phase out of the VFP app.

We recently replaced a smaller VFP app for these same clients, an app that helped run their handheld computers in the warehouse, using Visual Studio 2008 for the handheld computers app and VS 2012 for a web based app that replaced the VFP coding with calls to SQL stored procedures.  

That was a good approach for that smaller project, but what about something of a larger scope.  There are likely 100 forms and just as many reports in VFP app.  This will not be a small undertaking.

Any one out there with experience in this sort of project?  Any suggestions as to the best approach? Java, Visual Studio, ???

Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
It sounds like the client has a lot of spare money so he decided to spent them for application rewrite. Maybe it is clever decision because the rewrite will be more expensive later. But they should calculate what this "new" application can bring them...

Do they plan some new functionality?
How much it will cost? Or how many man years is planned for the rewrite?
Does the today's application still work? How long it can be working in the future?
Why they don't use today's application on-line? SQL Server allows it. Etc. Etc.

OK this is not answer to your question...

You should think about a few things:
1) Any port to Java, .NET, new reporting tool etc. does mean to start from a scratch - you'll write the same application again from ZERO. This is really the most expensive way but some companies have enough money and other resources...
2) Everything which is on-line is slower than the previous state.
3) To preserve some existing code you may look at FoxInCloud or Lianja. Both are new products and I don't know any case study of this extent. I still have no info about their stability and reliability. Another product of your interest could be ActiveVFP which helps to port VFP code to the internet.
4) VFP applications will be running for another 10-15 years. And when new operating systems become incompatible then we may use emulated environment which will be of the same quality and speed as todays native operating systems.

We are using VFP app on-line. The server part is coded as COM FoxPro DLL and the client part is also written in FoxPro. It serves hundred and more concurrent users over various kind of network connections (LAN, WAN, modems) without problems. The amount of data? About 40 GB. Stability? Amazing - no DBF corruption over years. So do we need something else? The only weak part is the Windows OS dependency.

Another way to going on-line is to use Terminal services.
Olaf DoschkeSoftware Developer

The question is, why the need for online usage arises. Growth of the comnpany, more regions? At least it doesn't seem it's just a phase out of VFP.

As you have a new part of the software with handheld devices it's logical to stay with Visual Studio, let it just be to stay with SQL Server. SQL Server can also be adressed with non MS languages, but in the end a .NET client is what is best supported from Microsoft.

It's not necessarily better to go web or cloud though, for a company internal software with sensitive data, privacy of personal data alone is a legal issue. You can sync several SQL Server databases, have central datacenter at the main location, there are many possible topologies thinkable without going to cloud services, without even moving to intranet applications. If the availability to use the software anywhere is a strong factor, you can reconsider web or cloud, but it's a paradigm change, even though web 2.0 apps feel like desktop apps.

Bye, Olaf.


Thanks guys.  As always, I appreciate your insightful and thoughtful responses.

This app is used by multiple clients in multiple locations.  Each location requires a SQL server installation.  There are multiple forms and reports that take too long to open/run over the internet connection to a remote SQL db.  I have SQL 2000 installed at 6 locations.  To upgrade all locations will cost my clients and/or myself A LOT.  The SQL upgrade obviously needs to happen and is part of the impetus to change how the application works all together.

Also, the clients want to be able to run the application from iPads, laptops, desktops, etc. and from any location.  

My hope is to be able to host the app locally here on a Windows server (I have a Linux server, but what a pain) and off a local SQL server installation, upgraded of course.

Does that make sense?  Rather than offering the program to my clients as a desktop app that requires a local SQL installation, I want to offer the program like or as a web app, capable of running anywhere, anytime on almost any device and still have it fast and user friendly.  My approach to this will be to start offering the highest value forms and reports online and eventually have the entire application available in the same manner.  In the meantime and maybe for years to come, the VFP app will continue to run and SQL dbs will continue to sync via replication.  

There are some variations in the applications between the three primary clients using it, so I will have to create three instances of the application.  However, they will be close enough alike that should not be increase effort/expense too much.  Plus, a web based approach to the program is easier to market, which I hope I actually have the time to try some day.
PMI ACP® Project Management

Prepare for the PMI Agile Certified Practitioner (PMI-ACP)® exam, which formally recognizes your knowledge of agile principles and your skill with agile techniques.

Olaf DoschkeSoftware Developer

>Rather than offering the program to my clients as a desktop app that requires a local SQL installation

Why do you think so, you can share one server to as many desktop clients as you want. All the clients need is a local SQL Server Driver installation, but they need a desktop app installation anyway and that's not hard to integrate into a setup.

> I want to offer the program like or as a web app, capable of running anywhere, anytime on almost any device.

You'll not host a web app on a local Windows Server. You'll need to open you web server (IIS on a Windows Server) to the internet. Not impossible, sure.

Bye, Olaf.


We have six Single Processor Licensed SQL installations spread out in multiple states.  Each installation is shared by dozens of users.  The issue is that SQL is expensive to keep up to date for these six locations AND I would like to add more locations.  What I am working towards is needing just one SQL installation shared by everyone from all locations.  

I am looking to Lianja and FoxInCloud and a total Java, PHP, whatever, rewrite.  This is going to be a challenge, but fun.  Slower performance may be the biggest problem, but the users are really looking forward to the online access, so I think a marginal drop in speed will be tolerated.  VFP is sooooo fast!  Like I said, the VFP app will remain intact, they just want additional access (FYI, we do have the VFP app online via VPN which works OK, but a successful web interface would be easier to access and use while on the road.)
Did you think about MySQL Server? It should be cost effective and the most compatible solution to MS SQL Server.
Olaf DoschkeSoftware Developer
With a database in the internet on a hosting space (eg a MySQL database) the database is local to the web server (Web server and database server can be separate, also for load balancing, but they will be near neighbours anyway, to have fast data access) .  It has a great advantage of not needing data replication etc, yes. The one server would need to be able to serve all users, and that's just a problem of proper dimensioning. Still you now only have your data central, no logic and UI, despite the many stored procs you already have, a wise move, if you stay MSSQL.

MySQL also isn't free for commercial use. Working with windows based hosting you'd be able to use MySQL, but also MSSQL, not only as web edition. MSSQL still means license fees, too, MySQL may be cheaper even if using a commercial license, but to recycle stored procs you'd stay MSSQL.

If the main part of the application runs on the web server, that means local data access no matter where users are. Choosing a web app approach you'd send out the forms, but in the form of HTML/CSS/Javascript, not graphical, which even means lower network loads than with a terminal server solution. Newer RDP solutions send out GDI+ or Direct2D drawing commands to windows clients, so that also has gotten rather light weight. The concepts compare in that aspect, your database is central, and local to code directly accessing it, business logic runs at the server, you just need to take care how much UI including the data displayed you send out to clients as that is the bottleneck, not the bandwidth from application to database.

Sounds like the way to go, but you may rather develop an API (eg RESTful with an interface based on OData protocol or Soap web services) which mainly would provide data to local running apps, either desktop or browser based. Maybe also a little client side logic (eg javascript) and widgets, in case of browser clients, but mainly the data resources. Choosing an API based solution that API could also be reusing VFP on the server side and reusing much of your business logic, if you didn't put it into your VFP desktop app forms. API requests first arrive at a web server, but that can trigger any local code or component, including VFP, on a windows server. No UI though, that wouldn't be visible to clients, at least.

A pure API with business logic and data access/storage has the advantage of being able to write device specific clients with native look&feel, which don't implement the application logic, but make the API requests for that matter, based on the data centric API.

Sure, you can also support several devices with a web application designed "responsive", but that mainly means responding to device dimensions and resolutions. That still needs much individual development for touch vs mouse/keyboard UI. The different devices are not only about the different sizes, but mobile devices rather need a very visual workflow, capable to be used with finger/touch gestures, eg picking from choices shown.

As advantage mobile devices open you up to use GPS for location or the camera for barcode scanning etc. Additional functionality you didn't have yet on the desktop. And you may not develop all UI for mobile, as you don't need all functionality of your whole application mobile.

So I'd go for a central concept for the functionality provided to the sum of all the different devices, also of all the different user roles and develop an API providing that functionality. Then create individual apps for the specific concepts for each device and user role. Limit the number devices you support, of course, eg only Win8 Phone or only iOS or only Android, ideally, not all of them.

The API based concept can be used by demand from several apps for different purposes, including the classic desktop as one of the clients. It's really making the best usage of a multi tier architecture, it may cost more than a single (web) application, but doesn't have any compromise as a one size fits all app.

Any functionality needs to be developed anyway, if for a single UI or for multiple. That part then still is only done once in case of a device specific separation of the UI. You would perhaps not reuse all functionality for each app and also develop some of the central logic only for some device, but otherwise would be able to recycle anything used by any two app implementations.

On top of all that, if you make your API (or parts of it) available public, you can have the effect of developers adding value, like there are many third party add-ons to ebay or like there are facebook apps, etc. That would need a strong user base or an exquisite user base and of course depends on what you would make available to the public, regarding both functionality, but also data. Letting anybody search your product database and offering the ability to place orders surely isn't wrong, even if you also offer an end user interface for that yourself, a developer might integrate that functionality elsewhere, where you wouldn't even imagine having a market.

Bye, Olaf.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial