Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
.NET isn't an RDBMS nor is it SQL Server, by the way. That's a pretty big difference. –  JohnFx Sep 13 '11 at 19:14
add comment

4 Answers

up vote 1 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
They also move around the country a lot because high paying Cobol jobs aren't common in every city. The same can be said for any fringe or antiquated technology expertise. –  maple_shaft Sep 13 '11 at 19:16
add comment

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.

share|improve this answer
add comment

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.
share|improve this answer
    
Tight coupling with data, in few cases, is beneficial. –  RPK Sep 13 '11 at 15:46
    
@RPK yes in few cases –  Gratzy Sep 13 '11 at 15:51
    
I feel tight-coupling with data is the strongest plus point of VFP, which you mentioned as minus point. –  RPK Sep 13 '11 at 15:55
    
@RPK - Unless you are dealing with those cases where the tight-coupling is beneficial, then it would be a negative. –  Ramhound Sep 13 '11 at 17:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.