What is Microsoft Visual FoxPro?
Self-employed fullstack developer with backend preferences.
Published:
Browse All Articles > What is Microsoft Visual FoxPro?
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
FAQ: http://msdn.microsoft.com/en-us/vfoxpro/bb190289
As in many other MS pogramming languages the "Visual" does not denote a visual programming language in the strict meaning of the term, but a visual programming environment with visual form designers. Before FoxPro was bought by Microsoft and upgraded to Visual Foxpro, there was FoxPro DOS and also UNIX and MAC versions, the DOS version was mainly used, and so UNIX and MAC versions were dropped. The added "Visual" mainly denotes VFP has a visual IDE and supports Windows UI. This is still limited to Winforms, WPF or Silverlight are a DotNet exclusive.
Microsoft rather recommends to take a look at VS Lightswitch 2011. I don’t agree, as this does not give a comparable experience, neither for VFP developers nor newbies. It integrates into the full VS, but itself rather is aimed for application generation by wizards and assistants and templates than for development of larger scale applications. It partly covers, what VFP also offers, as VFP also has wizards and builders, but you better cope without them.
What I agree is, VFP is not a language you should begin learning anymore, despite needing it to convert and migrate it. VFP has grown from the eighties to 2006, not resulting in an elegant overall architecture. It's having a steep learning curve for that matter and for not being very compact and lightweight. The steep learning curve also goes for DotNet but obviously pays more due to it's future perspectives. You can make up for this using third party application frameworks, which will make you more productive, but less learning VFP than the framework architecture. And of course there is a helpful community mentoring and helping you to go in the right directions, if you still choose to learn VFP. But the same options go for DotNet, too, again.
As a developer newbie wanting to do a databased application, either go Access for really small apps, for which you can live without OOP classes, etc, or go for the real deal VS.NET - even just the Express versions offer a good consistent architecture.
For VFP developers, though, which have not yet migrated and extended their know how, VFP is still a good tool to create and maintain small to medium size database applications with a magnitude of 100 users and even better scalable, when using an SQL Server as backend database instead of native database files.
The FoxPro community is still rather active for being 5 years past discontinuation and a VFPX project formed on Codeplex around Sedna extensions generously released by Microsoft to the public domain, which were developed so far in the aim of VFP 10.
And besides this, VFP developers of course look for successors of VFP, which is the topic of the final section of this article.
Backup and Restore can obviously be done on the file level, any backup software can be used, ideally off-hours, or choose something with a snapshot feature.
VFP is no database server, every client directly accesses the table files, even if you introduce a so called database container (DBC), this merely is a lookup table itself containing some meta data info about the tables belonging to the database, eg their file names. It also contains stored procs (including DML triggers) and dbc events (DDL triggers). Both types of triggers can make use of the full VFP language.
VFP data also supports transactions, which work without an sql server and are communicated to other clients by making use of several file lock types. Manual table and row locks also enable you to do manual locking and VFP also offers buffering of changes instead of or additional to transactions. VFP transactions only conform to three ACID properties Atomicity, Consistency and Isolation, but not to Durability. No transaction logs are written, in case of a system failure, the result is loss of transactional data, meaning a roll back to the pre transaction state. At least that's making transactions fail gracefully. The same goes for buffered changes.
Like Access, VFP can also link to external databases via ODBC drivers or OLEDB Providers.
Like Java, VFP is compiled into object code consisting of tokenized byte code. These byte tokens are run by the vfp runtime, which does no further just in time compilation on the specific cpu architecture an exe or dll runs. This makes VFP an interpreter with a precompiler rather than a compiler language, still you compile to EXE and DLL and need nothing but Windows and the runtimes to run a VFP executable.
You can create n-tier applications with VFP by it's OOP nature and COM support.
There is much more to say about this, for example it’s getting more complex, if the VFP database also has stored procedures, we’re back on the topic of migrating application code.
Still aside of stored procedures migration one thing to mention here is Sybase Advantage Database Server, which offers a newer 32bit and 64bit ODBC driver also usable for native VFP9 data, as long as no stored procs are involved.
Product Description: http://msdn.microsoft.com/
FAQ: http://msdn.microsoft.com/
As in many other MS pogramming languages the "Visual" does not denote a visual programming language in the strict meaning of the term, but a visual programming environment with visual form designers. Before FoxPro was bought by Microsoft and upgraded to Visual Foxpro, there was FoxPro DOS and also UNIX and MAC versions, the DOS version was mainly used, and so UNIX and MAC versions were dropped. The added "Visual" mainly denotes VFP has a visual IDE and supports Windows UI. This is still limited to Winforms, WPF or Silverlight are a DotNet exclusive.
Does It Pay To Begin With VFP?
VFP was discontinued in 2007, also VFP is in the last support phase of the Microsoft support lifecycle - called extended support - which ends January 2015. Microsoft doesn't sell VFP anymore, mainly because it would then need to make warranties exceeding that end of support date.Microsoft rather recommends to take a look at VS Lightswitch 2011. I don’t agree, as this does not give a comparable experience, neither for VFP developers nor newbies. It integrates into the full VS, but itself rather is aimed for application generation by wizards and assistants and templates than for development of larger scale applications. It partly covers, what VFP also offers, as VFP also has wizards and builders, but you better cope without them.
What I agree is, VFP is not a language you should begin learning anymore, despite needing it to convert and migrate it. VFP has grown from the eighties to 2006, not resulting in an elegant overall architecture. It's having a steep learning curve for that matter and for not being very compact and lightweight. The steep learning curve also goes for DotNet but obviously pays more due to it's future perspectives. You can make up for this using third party application frameworks, which will make you more productive, but less learning VFP than the framework architecture. And of course there is a helpful community mentoring and helping you to go in the right directions, if you still choose to learn VFP. But the same options go for DotNet, too, again.
As a developer newbie wanting to do a databased application, either go Access for really small apps, for which you can live without OOP classes, etc, or go for the real deal VS.NET - even just the Express versions offer a good consistent architecture.
For VFP developers, though, which have not yet migrated and extended their know how, VFP is still a good tool to create and maintain small to medium size database applications with a magnitude of 100 users and even better scalable, when using an SQL Server as backend database instead of native database files.
The FoxPro community is still rather active for being 5 years past discontinuation and a VFPX project formed on Codeplex around Sedna extensions generously released by Microsoft to the public domain, which were developed so far in the aim of VFP 10.
And besides this, VFP developers of course look for successors of VFP, which is the topic of the final section of this article.
The Database in short
VFP tables are royalty free and have a per file limit of 2GB. By this definition a database has no overall size limit, but you need to watch your fastest growing tables and either archive or split data.Backup and Restore can obviously be done on the file level, any backup software can be used, ideally off-hours, or choose something with a snapshot feature.
VFP is no database server, every client directly accesses the table files, even if you introduce a so called database container (DBC), this merely is a lookup table itself containing some meta data info about the tables belonging to the database, eg their file names. It also contains stored procs (including DML triggers) and dbc events (DDL triggers). Both types of triggers can make use of the full VFP language.
VFP data also supports transactions, which work without an sql server and are communicated to other clients by making use of several file lock types. Manual table and row locks also enable you to do manual locking and VFP also offers buffering of changes instead of or additional to transactions. VFP transactions only conform to three ACID properties Atomicity, Consistency and Isolation, but not to Durability. No transaction logs are written, in case of a system failure, the result is loss of transactional data, meaning a roll back to the pre transaction state. At least that's making transactions fail gracefully. The same goes for buffered changes.
Like Access, VFP can also link to external databases via ODBC drivers or OLEDB Providers.
The Programming language in short
The programming language rather compares to Visual Basic language and supports both procedural and OOP programming styles. It's dynamically typed, still data is strongly typed and functions and expressions are strongly typed and won't do but a few implicit type conversions of numeric types.Like Java, VFP is compiled into object code consisting of tokenized byte code. These byte tokens are run by the vfp runtime, which does no further just in time compilation on the specific cpu architecture an exe or dll runs. This makes VFP an interpreter with a precompiler rather than a compiler language, still you compile to EXE and DLL and need nothing but Windows and the runtimes to run a VFP executable.
You can create n-tier applications with VFP by it's OOP nature and COM support.
Pros and Cons
Pros
VFP is OOP, it offers not as much oop features as DotNet, but much more than Access with it's class modules. VFP offers the most important of course: inheritance. It also supports private and hidden methods or properties, but no interfaces and no events can be user generated.
VFP is very resource friendly, yet quite capable in working on several GB data (comparable to SQL Express or LocalDB). The VFP9 IDE can be used in Win2k or later and created EXEs can be used in Win98 or later.
VFP databases are royalty free, no CALs nor CPU licenses are needed.
VFP has SQL built in, it's part of the language, not seperate command strings you send to databases. It compiles and verifies at that stage.
VFP offers a feature of macro substitution, which means single line code generated and compiled at runtime, but even COMPILE is a command the runtime supports.
Interoperability end Extensibility: VFP supports ODBC and COM/OLE and is capable to connect to remote databases, do OLE automation of office applications and any other OLE automatable applications besides of course parameterized command line calls to other executables. You can also make use of COM DLLs and stdcall function DLLs. The latter in a special form of FLLs can also expand the instruction set with Functions.
VFP supports Webservices, eg via Soap Toolkit or third party XML Tools, both as server or client, and if you just use MS COM XML parsers and serialisers.
VFP can build COM Server DLLs, including multithreaded DLLs. These also can form the base of web services, which can be published via the Soap Toolkit or manually via DCOM/COM+ in IIS, some third party extensions bring VFP to the web this way.
Cons
Unicode support is very limited to a few string functions for conversion, the OS API offers more, there is no native control to display Unicode, but VFP supports ActiveX controls. VFP-Tables are generally coed in ANSI code pages including support of fontcharsets/scripts, which means double byte ANSI charsets. There are no Unicode field types, too, but binary field types can store anything, including Unicode texts, of course.
Security: VFP Databases can be encrypted using third party tools or the Windows Crypto API, but access rights or roles on the data have to be implemented on the NTFS file access permissions level.
Stability: DBFs have a bad reputation to often become defect. So do MDBs. Proper used, this is just partially correct. The most often header defect can be repaired with native VFP code, and there are third party tools to repair tables and related files. In single user mode on local HDDs, FoxPro databases are usable maintenance free, as most all defects have their root in concurrent file access and network errors, which then of course don't occur.
Size limitations: As already discussed, there is no overall limit but a per 2GB per file limit.
Successors of VFP
There are quite a bunch of candidates aiming towards VFP developers, who look for new directions. There are four main categories:1.
Languages, which - like VFP - evolved from the original dBase or Clipper, namely xBase++ and xHarbour.2.
VFP itself and it’s community extensions, namely VFPX at Codeplex and some more side projects3.
Some cloud based alternatives, from which FoxInCloud is stongly Foxpro based, not aiming for migration of the language but just the infrastructure. The same goes for ActiveVFP and VFP2IIS. Lianja supports Fox as one language and Servoy, which aims for Javascript developers and is Java based itself.4.
Efforts to reimplement Foxpro, which include Guineu (a DotNet based VFP Runtime, bringing VFP to Windows Mobile or other DotNet Framework supported platforms, VFPCompiler for .NET compiling Foxpro code as .NET apps and assemblies and Visual FreePro, as a new candidate in that range.I don’t mention Java and DotNet as successors, because they are a league of their own. They surely are a big option not neglectible but aside of the feature shrinked Lightswitch don’t aim for VFP developers. For professionals they are of course enabling you to go further into the enterprise league.Database Migration
VFP Data can be easily converted and upsized to any server database from MySQL up to Oracle. As mentioned, VFP can make use of ODBC drivers and OLEDB Providers, opening the full range of third party databases. Surely MS SQL Server is one good new home of VFP data.There is much more to say about this, for example it’s getting more complex, if the VFP database also has stored procedures, we’re back on the topic of migrating application code.
Still aside of stored procedures migration one thing to mention here is Sybase Advantage Database Server, which offers a newer 32bit and 64bit ODBC driver also usable for native VFP9 data, as long as no stored procs are involved.
Self-employed fullstack developer with backend preferences.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (12)
Commented:
In order to optimize efforts I'm planning to use a PHP based framework to produce for Windows Forms : PHP-GTK classes or other more convenient (if exists).
When migrating from VFP to PHP I put the more heavilly DB acttions in MySQL as SP(s) and SF(s) so the data layers are separeted from the view layer.
So if it could be done in PHP I'm going to have similar code to do the job independently of being internet or Windows Forms. Investing only in PHP...
Commented:
Author
Commented:Well, it's everybodies own decision and not the core PHP function, but you can do PHP local, too, be it in a intranet or from a web based central installation. You can have a html frontend working with a cloud or classically hosted application and on intranet. The last mile not coverable with PHP in general is about local devices, but you don't necessarily need a winforms app to integrate them, it's just simpler, but the overall .net solution typically is neverhteless asking a lot more architectural knowledge from you, a VFP developer typically misses.
PHP is of course no single language able to replace VFP, but its integration with MySQL is a symbiotic pair very well covering the package VFP and DBF are, minus frontend. So, yes, of course there is a lot to do to add HTML and CSS and Javascript/jQuery or other stuff, and even assuming you have that knowledge you have a barrier to local resources you have to bridge somehow, eg for integrating barcode scanners or electronic scales used in many applications from POS system to lab software. That could be a part submitting it's data to some layer accessible by JQuery or PHP. For example take a look at http://phppointofsale.com/. Watch the video, which demos at about 2:00, how this browser based PHP application can be used by shop clerks to scan in products and print a receipt.
I don't say PHP is covering all needs, as it only is one part even of simpler web app, you have to add a frontend. But as I said in the article:
If you're fine to go that route anyway and get forward and have anything you need there, then that's your solution, but there are also those, who already used VFP to do web applications with west wind packages or AFP or FoxWeb and others, and for those PHP surely is a good successor. You often don't need to address local resources, then that part not covered by a browser frontend also becomes unnecessary. So I still stick with my recommendation for PHP as one general solution often overseen, just because it's no desktop solution.
Bye, Olaf.
Commented:
Thank you for your concerns. I'm going to better research your suggestions.
Commented:
Write to Chen <ccb2000@163.com>. He provides an upgrade to VFP (Versions 10.0 and 10.1) that operates on both 32-64 and 64 bit Windows. His code is now FLAWLESS. My company it continuing with VFP into the far future now. We have two popular commercial products written in this new language.
Frank Moore (fmoore@fwmsoftware.com)
View More