Solved

Rewriting a VFP 9 application into a web based application

Posted on 2014-02-26
7
1,785 Views
Last Modified: 2014-03-15
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, ???

Thanks!!!
0
Comment
Question by:woodwyn
  • 3
  • 2
  • 2
7 Comments
 
LVL 41

Accepted Solution

by:
pcelba earned 250 total points
Comment Utility
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.
0
 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
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.
0
 

Author Comment

by:woodwyn
Comment Utility
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.
0
What Security Threats Are You Missing?

Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

 
LVL 29

Expert Comment

by:Olaf Doschke
Comment Utility
>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.
0
 

Author Comment

by:woodwyn
Comment Utility
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.)
0
 
LVL 41

Expert Comment

by:pcelba
Comment Utility
Did you think about MySQL Server? It should be cost effective and the most compatible solution to MS SQL Server.
0
 
LVL 29

Assisted Solution

by:Olaf Doschke
Olaf Doschke earned 250 total points
Comment Utility
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.
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Suggested Solutions

Microsoft Visual FoxPro (short VFP) is a programming language with it’s own IDE and database, ranking somewhat between Access and VB.NET + SQL Server (Express). Product Description: http://msdn.microsoft.com/en-us/vfoxpro/default.aspx (http://msd…
In this article, you will read about the trends across the human resources departments for the upcoming year. Some of them include improving employee experience, adopting new technologies, using HR software to its full extent, and integrating artifi…
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…
This video demonstrates how to create an example email signature rule for a department in a company using CodeTwo Exchange Rules. The signature will be inserted beneath users' latest emails in conversations and will be displayed in users' Sent Items…

771 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now