Wiki Home

Talk : Visual FoxPro Bullet Points

Namespace: WIN_COM_API

A Place To Talk About Visual FoxPro Bullet Points
Also see: Overcoming Objections

That is a balanced and reasonable way to promote/justify the use of FoxPro. Thanks! - Guy Pardoe

Hmm... Has it occured to someone that there is no reason why NOT to use Foxpro?

Foxpro is advertised as a Database Application. Still, the platform can be used for other purposes. For example, I recently made a Foxpro program to browse and play .mpgs on a CD.

We are confining Foxpro to the Database realm... Big mistake.

Visual Basic is advertised as a "can do anything" tool. And it stinks in databases. I bet I can do more with Foxpro than with Visual Basic - more easily and more quickly... and I'm not just talking about databases.
Quite frankly you always need to be aware of limitations in order to mitigate development risk. It's only by knowing strengths *and* weaknesses that you can properly balance the sometimes conflicting forces, and make proper decisions. I can think of a lot of reasons not to use Foxpro on any particular project. Picking the wrong development environment for a project sets the stage for the worst possible outcomes for all parties.-- Steven Black
I would like to add to this that one should not just know the strength and weakness of the product but more than that, and you say that in other words as well Steve, how the product compares to other tools.
Like you say, picking the wrong tool for a project is devastating, however, this can be a counter-argument as well as very often (and those Very Fine Programmers are guilty to that as well) a tool is chosen based on emotions, not on clear thinking.

Also, some other topics to put in the list are TCO, time to develop and deploy compared to other tools. For this, good knowledge of those other tools is quite a must.
I recall an article from Les Pinter telling that when it comes to showing the possibilities he first shows the power of .NET in a way that makes managers enthusiastic, then gives a figure on how long it will take him to develop an app as they ask and THEN tells them it can be done in 1/3 or so of the estimated time, using another tool, VFP.
can anybody confirm that article? (and please tell me where to find it?)
Boudewijn Lutgerink

I'm pretty sure I read that in a VFUG newsletter a few months back. They're at
Guy Pardoe
Speaking of bullet points, the article at has several good ones. Randy Bosma
VFP certainly isn't the right tool for every software problem. But is .NET that ? Or Delphi, Java or Perl maybe. I don't think so. Every tool has it's strengths and weaknesses. VFP just happens to have a lot of strengths. And talking about bullet points : VFP is still alive and kicking after ten years of marketingsilence while .NET is having a hard time getting a decent market share with millions of dollars of advertising spent on it. And if you feel like you should learn about .NET (like I do), you should also learn about Java (and J2EE) or at least take a very close look at it. Maybe you'll get confused again which tool to use !
Somebody just posted this, and I moved it here, pending discussion.-- Steven Black
Some interesting points considering TCO (total Cost of Ownership)
  • Working with local databases, no license costs. thus very attractive for small companies.
  • Database is easy to upsize through the upsize wizard. Thus, if your company grows the database will follow your company's growth.
  • Works with a plethora of back-end databases going from MS SQL to Oracle, Cache, MySQL...
  • Due to the strong and practical OOP model, component reuse is possible, leading to shorter development cycles and faster deployment.
My thoughts:
  1. Local tables are actually a big downside for most corporate customers for reasons of security, reliability, scalability, backup, etc, and the 80% use case for Visual FoxPro Bullet Points implies a back-end data store because this is what bigger customers often require.
  2. The upsize wizard isn't particularly good, in my view, and moreover it's not something you want to be talking about at the level of abstraction implied by Visual FoxPro Bullet Points -- a meeting with senior IT management people.
  3. I'm not sure the point about "shorter development cycles and faster deployment" is supported by any evidence other than hearsay, so it's questionable that you'd want to bring this to the table without any possibility of supporting evidence.
-- Steven Black
When it comes to shorter development cycle I think the estimate tool from construx speaks for itself when you make a calc on both 4 generation RAD tool or a tool like C#. Actually, that comes close to my own experience.
-- Boudewijn Lutgerink
reply to "my thoughts" :
  1. If what you need is security, reliability, scalability, backup, etc, just use SQL server, Oracle, Pervasive SQL, ... or MySQL if you don't want to spend money. VFP handles each of these servers pretty good and easy (as good as any other tool, maybe even better). And having a local data engine always comes in handy even if you use a database server.
  2. The upsize wizard is something you should never use! A good VFP developer goes OOP and develops his own data access classes which should easily connect to any data backend including Fox tables with very few changes in code.
  3. I'm not sure the point about "shorter development cycles and faster deployment" either, but if I had to bet on it I would say that the Fox scores pretty high on that level too.
-- Frank De Baere
As to the use of the upsize wizard, I do try to prevent it when possible. However, it is a tool one CAN use to visually create a database and upsize it so after that development can be done on another backend. Of course, with the Cursor Adapter this technique will become obsolete. (as is the use of views anyway!) But it CAN be a selling point depending on the company we talk to.
And, but please do correct me if I'm wrong, that is what the bulletlist is all about, collecting USP's for VFP.
-- Boudewijn Lutgerink
Perhaps what's needed here is alternative bullet points depending on the client. I imagine that if you're proposing an app for your cousin's used clothes store, local data would be a bonus, particularly on a slower box or older OS. -- Zahid Ali
Foxpro bullet points? Don't believe any of them! Just insert that VFP installation CD into you drive, install it and take it for a ride. Try VFP out. Create a database with some tables, reports, run some queries, create some forms, check out the class browser, object browser, ... Just let the tool convince you instead of the talk on this page. And if you're interested, check out some (big) apps written in Fox, surf to some Fox sites, ... Read, listen, learn, ... You just might be amazed what this tool can do.
We know what this tool can do, and, but that's just a wild guess, I think most of the visitors here have done just that, install the tool.
What this is about is how to bring the message of VFP being a good tool to those PHB types.
-- Boudewijn Lutgerink
Last evening I accidently saw the Windows 2003 .NET server advertising spot on a bussiness tv chanel. "Windows Server 2003, Do MORE with LESS" it said. I can (cautious) believe about the "MORE" part (after all it would be a major screw up if Microsoft released a 2003 version that would have less capabilities compared to it's predecessor). But the "LESS" part??? Has anyone noticed how much resources a .NET app consumes? Of course it's fast; if you put it on the latest P4 512MB RAM machine (which is probably a minimum if you want to keep things decent). FoxPro is very fast and capable on much smaller machines consuming much less memory and other resources even when it is put under heavy load. "Do MORE with LESS" sounds more like a VFP ad to me.
--Frank De Baere
I agree. One of the biggest benefits of VFP is the small footprint compared to something like VB. If you are doing internal development or travel to sites to install your app that's not as big a deal. But if you are developing a site for distribution to a lot of different customers with a lot of different system setups VFP is much easier than trying to distribute something like VB, .NET, etc.
I agree and disagree. Costs for hardware is hardly an issue in any PHB meeting. With the costs for memory, HDD's and what's more being quite affordable the hardware is never discussed any longer then 5 minutes. It's more like, "OK what do we need to run this software... blablabla... OK, let's buy it."
However, when it comes to software the discussion can go on for quite some time. Not that those PHB types know a lot of the state of the tools but they are good in PRETENDING they know all about it, only a very few do know what they talk about.

Boudewijn Lutgerink
I agree that spending money on mem, hdd's, ... is no big deal and not something that managers argue about. Remember however that we are in Europe here. Everybody can aford (or wants to brag about) having the lastest hardware. This is a whole other story in some other (not so small) countries around the world. It also seems like a good USP being able to tell the managers that your Fox app will consume less and (probably) run faster leaving more resources free for other services/programs.
--Frank De Baere
Recently I read a lot. Technical stuff indeed but not on developing software.
I visited sites with as main subject "selling", read books on sales.
All the marketing issues brought up in the Visual FoxPro Bullet Points list miss one thing.
WHAT do we sell (or want to sell)? Do we want to sell VFP or do we want to sell a solution, helping that particular customer doing his/her business better and more successful where the took we use is VFP because we are well trained in that? Basically I don't think the customer would really care with what tool the solution is created, either VFP, VB C++, C# or any tool. What the customer cares about is the fact that the problem he/she is facing is solved in an elegant and working way. Techie talk is hardly interesting for them and once we go into that discussion with customers you lose the contact with the client.

Maybe we should focus on gaining more knowledge on sales techniques, based on psychology, good conversational practice and real interest in the customer's daily work.
If that would help in getting more prospects with eventually more assignments it's just my guess we would be happier.
Just my $0.02 new year's consideration. Happy 2004 everybody, happy foxing!

Boudewijn Lutgerink
Overcoming Objections A place to provide specific suggestions for how to refute (or clarify) objections to FoxPro that might be raised during the presentation of Visual FoxPro Bullet Points.

Productivity Issues

Objection: FoxPro is not a real database management system. Its files are prone to corruption.
  1. What do you mean when you say "FoxPro"? FoxPro the database manager lacks many of the features of a "true" database management system, and programmers who use it must know how to deal with the potential for file corruption. Nevertheless, there are situations where the native FoxPro database system is appropriate. On the other hand, FoxPro the language has a fantastic DML (Data Manipulation Language) which is completely independent of where the data comes from. It can come from a true database management system such as SQL Server, a simpler database system such as Access or FoxPro, or even Word documents. Once the FoxPro program gets hold of the data, the sky's the limit.

  2. Visual FoxPro IS a "real" database management system. Those who claim otherwise are ignorant of what "database management system" means. (Yeah, I know, you don't call the PHB ignorant to his face if you want to promote VFP. But at least, let's not us here buy into this fallacy.) A database management system is a system that allows you to manage relational databases. The VFP native data engine is a fully relational database system. Furthermore, it supports buffering, and transactions that can be rolled back. It has a robust implementation of SQL (which has been greatly enhanced and improved in VFP 9). It supports stored procedures. It supports remote access. It supports 24/7 operation with continuous backup capability (physically copying a file from one location to the other isn't the only way you can backup data in VFP). The data can be encrypted. The data can be secured if deployed on a secure OS. You can write a server in VFP and create a true client/server application. It has been successfully and reliably used in systems that store millions of records that are accessed by hundreds of users across broad geographic areas. Maximum table size is 2 GB but there is no limit on how many tables can be used in an application and a knowledgeable designer can construct systems that can handle a few hundred GB of data. The VFP data engine is not fast enough to support huge enterprises that must manage terrabytes of data and access by thousands of users. But its programming language is, and it can work with all of the most popular proprietary and open-source back ends. And really, how many such enterprises are there? VFP has massive growth potential among underserved customers that do not fall into the category of "huge enterprises". And let's not forget that set-based database management systems are optimized for reporting aggregate data and are relatively inefficient for applications in the medical and human services fields where the focus is on frequent small set access, analysis and complex calculations, whereas the VFP data engine shines in those areas. As for file corruption in VFP: most of it can be traced to poor application design and/or coding, and hardware failure. As for the rest--any database system will screw up if somebody pulls the plug on the server, and a sound backup strategy reduces the entire issue to a triviality. -- Ken Dibble

Developer Community Issues

Objection: VB and .NET programmers are cheaper and easier to find (especially in less populated areas) than FoxPro programmers. I need to know I'll be able to find someone to maintain your code after you're gone.
  1. "You get what you pay for." An experienced programmer who's any good will not be cheap. It's true you probably can't find an inexpensive FoxPro programmer, but that's because most of them have lots of experience. Because .NET is so new, even an experienced programmer will still be low on the learning curve and therefore take longer.
  2. Note to the FoxPro community: we need to find a way to get young people to learn FoxPro. Is there any way for us to encourge companies who are hiring entry-level programmers to teach them FoxPro?
Finding an experienced .Net developer will be very difficult, given the relative youth of the language, and the slow rate of adoption in the developer community. Here in L. A. agencies are attending .Net user group meetings and offering 100-120/hour for experienced .Net developers. They aren't getting any takers. Because they are ALL already working. A room full of junior to mid-levels, though. But nobody willing to stand up and hold themselves as a senior, even at those attractive rates.

Category VFP Marketing
( Topic last updated: 2006.07.28 06:44:44 PM )