Comparing Visual Foxpro with .NET

Question

I used Foxpro 2.6 a decade ago. In my present company, few new projects are being developed in Visual Foxpro 9.0 and few projects are on .NET platform. From time-to-time I notice how Visual Foxpro is more powerful as compared to .NET when comparing dependency issues.

Here are some of the advantages of VFP I noticed:

1. There is no hard and fast rule to use another full-fledged RDBMS. Even though the latest version of Visual Foxpro can be connected to SQL Server, but I have seen very large projects still, happily, using the old DBF. With .NET you have to connect to another RDBMS and it just adds to your Setup dependency.

2. Foxpro has built-in rich reporting capability since the time of DOS era, whereas .NET developers have to depend on Crystal Reports, SSRS or other third-party variants.

3. Visual Foxpro 9.0 has .NET capabilities as well. However, it is not dependent on .NET and therefore your final executable doesn't need .NET framework installed, which is again a dependency.

4. I have seen very large databases of Foxpro in few major government organizations, successfully running from a long time. These organizations don't feel a need to shift to SQL Server, not because of migration risks, but because they are happy with VFP.

I want to step into VFP world but I read somewhere that Microsoft is stopping further developments of VFP and also stopping support to VFP 9.0 from 2015 onwards.

What you guys suggest?

Answer 1

There is no hard and fast rule to use another full-fledged RDBMS. Even though the latest version of Visual Foxpro can be connected to SQL Server, but I have seen very large projects still, happily, using the old DBF. With .NET you have to connect to another RDBMS and it just adds to your Setup dependency.

no you don't have to connect to anything :) . This is fine if you want tight coupling of data/application as others have mentioned. However from a design prespective this breaks down quickly when you want to scale the application. What happens when you have a very heterogeneous system that has to interconnect to multiple platforms? web/desktop/mobile etc. In this case de-coupling the code from the data-store is the normal route.

Foxpro has built-in rich reporting capability since the time of DOS era, whereas .NET developers have to depend on Crystal Reports, SSRS or other third-party variants.

Again, you don't have to depend on anything. Most "reports" are either spreadsheets or pdf (insert other format). As you have mentioned 3rd party components are available. Most projects I've worked on use custom built solutions, code-reuse means that the investment is one off.

Visual Foxpro 9.0 has .NET capabilities as well. However, it is not dependent on .NET and therefore your final executable doesn't need .NET framework installed, which is again a dependency.

If you are targeting the Windows platform, this is a poor argument. Further there are solutions that can run .NET without needing the .NET runtime e.g http://spoon.net/ or others that bundle everything into a single executable. Using silverlight/Asp.net you could also host your application as a thin client.

I have seen very large databases of Foxpro in few major government organizations, successfully running from a long time. These organizations don't feel a need to shift to SQL Server, not because of migration risks, but because they are happy with VFP.

Many companies are also happy with COBOL, however things have improved vastly since then. When the option is available to use newer technology platform, there are no real reason to use legacy platforms.

Answer 2

If you are living in a world where an app tightly coupled to the storage and only speaking relational gets the job done, then no, there really isn't much advantage of moving on from VFP.

That world is getting smaller and smaller. And the last version of VFP was released in 2007 and it is pretty clear that the platform has been given the old heave-ho by Microsoft. I definitely would not develop anything new in VFP.

On the other hand, there are some FORTRAN and COBOL guys who work 10 hours a week and drive porsches.

Answer 3

I was mostly a VFP developer (from FPDOS) until this year so I can understand where your coming from.

The problem as I see it isn't capability. As it is, VFP is able to deal with most requirements without flinching, sometimes even outperforming the more popular alternatives.

The problem is the marketplace and the changing environment. In the eyes of most people, VFP is no longer part of the Microsoft "stack". That means your salespeople will meet greater resistance as time goes on. It also means less and less people will be learning the language, which means you might have support issues even if its an in house application.

I love VFP and still curse at random moments when I'm working with C# and .NET but it was something that had to be done. Sticking to VFP would have just been delaying the inevitable. Sooner or later, it WILL become an issue and if that's going to be the case, you might as well make the switch now.

Answer 4

I have worked in both and there are plenty of reasons VFP is less desirable to build applications in. Here are a few.

• 2GB table size limitation
• Forms, code, everything very tightly coupled to the data.
• If you are going to use it as just a front end to other data sources i.e. sql server then .Net offers much more flexibility.
• Availability of developers, I have found that there are very few people left developing in VFP.
• And of course there are no more future versions being released.