One of these topics is the comparison between Access and FoxPro, visual or otherwise.
Partly because of my long association with one tool, or language, (where I have been increasingly amazed over the years with its power and flexibility), I have a curiosity about other tools, or languages, which may bear some similarities, especially if I have had no contact with them.
So, unlike some topics, where I either skim or skip, I have read these messages about Access versus FoxPro much more carefully, trying to squeeze as much understanding out of them as possible. I have tried to stay open-minded a little bit, but I don't have much reason to be open-minded, because my job requires me to use FoxPro (of several flavors). And, I'm glad I have this job, because I really like FoxPro, and I like to program in it. But, I'm glad people took the time to compare them, because now I know more about what Access can (and can't) do.
Here is a compilation of what I could find on this topic, ranging from comments from Universal Thread members, to a chart which compares features. At the end, I have one or two conclusions.
How does MS Access compare with Visual FoxPro?
This is a question which arises frequently.
Michel Fournier thought it would be helpful to "distill" the comparisons into one Knowledge Base article for future reference.
Editor's approach:
Maximum MDB size [Access] is 1.2 GB. A FoxPro table is limited to 2GB with no limit on the database size. -- Daniel Byers, II
Here are 3 reasons:
Reality: Why is Basic more modern than xBase? dBase III was released in the early 1980s. Basic was created in 1960. Basic "without line numbers" even predates xBase by maybe a couple years. Error handling in Visual Basic still requires you to use "GOTO." If that's modern, I don't know what outdated means.
Reality: It takes a lot of learning for legacy programmers to use VFP OOP capabilities properly. If you have used VB, you will shorten the learning curve as you learn to invoke object. But using VB by itself won't get you *over* the learning curve, because VB offers no place to go with OOP.
Reality: In many cases reported in this news group, VFP is actually faster. (I haven't saved the references). But it's a moot point when dealing with database intensive work. For manipulating local data, VFP is definitely faster. For manipulating client/server data, you won't gain any speed by converting to VB, (or even C++ for that matter).
Reality: It is true that VB is Microsoft's strategic language of choice. This was true before Microsoft bought Fox Software. But Microsoft has definitely not abandoned VFP. Major releases of VFP (3.0, 5.0) have occurred twice in the last two years. Minor releases (3.0b, 5.0a, 5.0 SP2) have occurred 3 times. The VFP development team is quite talented and is working on a new release VFP 6.0 also known as "Tahoe".
Reality: VFP 5.0 supports full ANS SQL capabilities, including outer joins. These can be performed on both local and server data. While VFP also supports older xBase constructs such as SET RELATION, you do not need to use these to use VFP. As a client/server tool, VFP offers GUI control of views and connections and is able to control connections better than VB. Additionally it provides both native SQL for server data as well as pass-through.
Reality: There is no particular reason why this is an either-or decision. You can use VFP with Office tools just as you can use VB with them. Over the last 10 months, VFP 5.0 has maintained better compatibility than VB 4.0 or VB 5.0 and has had few if any installation conflicts with Office 97 and Office 95. I've used it with both under both Win95 and NT 4.0. For local data, you can store information in the DBC and easily reach it from Access 95 or Access 97. Doing so provides you with better physical control of data storage than storing data directly in an MDB. There is also no reason why not to use both VB and VFP on the same project. VB is a good Windows development tool, but not primarily a database tool. Both tools can use the same controls. Using both of them might provide you with the best of both worlds, plus they are packaged together in Visual Studio. In today's world, there are new development tools appearing at the rate of about 10 per day. Programmers are going to be better off knowing more than one language and need to be able to use class inheritance (or its equivalent, object delegation). You can use VFP without learning inheritance, and it has an easy to use "Save As Class" menu item, so VFP gives you a rather gentle introduction to OOP. -- Richard Katz and Tony Miller
Microsoft Access is part of Office Microsoft Visual FoxPro is part of Visual Studio.
VFP is a programmer tool. As an example, tinkering under the covers of a master-detail form is nearly impossible in Access, whereas it is a breeze in VFP. The Access database uses variable length records. This is fine for small data files, but as the number of records grows, navigation becomes slower. In VFP, getting to a given record is done by simply multiplying the record number times the record length and adding the number of bytes taken up by the header. In Access, getting to a specific record is not possible in this way.
The design philosophy differences are dramatic and not to be underrated. The two products feel quite different. Access is very intuitive and easy to use at first. But as the application becomes more complex, the programmer ends up fighting with Access. It wants to do things one way and the programmer needs to do it a different way. In VFP, there is almost nothing that cannot be accomplished. This is simply not true in Access.
Don't let end-users dictate programming language choices to you. If they insist, you will be working for a client (boss?) who should not be making those types of decisions, and you will be very unhappy (poor/broke/sued/worse). -- Ray Kirk
To brighten you all up a little, not all companies shun FoxPro. I can look in the Sunday employment section to find enough VFP positions to know that I don't have to worry should I lose my current full-time job (writing a huge medical analysis app in guess what....VFP 5.0). My independent work has just signed on as a sub to an insurance company rebuilding an app in guess what....VFP 5.0. Clearly everyone on this board is working with FoxPro so I think that we are all going to be around for some time to come. Although M[icrosoft] has made our marketing efforts more difficult, I find that I can usually overcome these and get a client to see that the minimal expense of VFP, when compared to other per user licensing arrangements, and the proven technology of Rushmore far outweigh the comments that they might make. We may not quite yet be standing on cement, but at least it's not the quicksand of a few years ago. -- Steve Despres
Account 1 Account 2 Account 3 Manager Employee Mngr1 Emp1 8 7 2 Mngr1 Emp5 1 2 4 Mngr1 Emp7 4 0 8 Mngr2 Emp3 9 9 9 Mngr2 Emp4 9 7 0 Mngr3 Emp2 0 0 9 Mngr3 Emp6 9 2 4 Mngr3 Emp8 3 5 3
You can go around the [above] problem by running the query in two steps:
I'm trying to get 3 new portables for my team and me. I asked for high end ones, suitable for applications development. The conversation went as follows:
IS: What apps are you developing and what language/software do you need? Jen: Several apps in VFP 3.0, upgrading to VFP 5.0. We already own VFP. IS: You can't develop in VFP, it's not a supported product. You have to use Access. We can't support VFP. Jen: I don't need support. I have a team of 3 people with a combined 24+ years experience in xBASE language development, 8+ in VFP 3.0/5.0 alone. IS: You have to develop in Access -- it's company policy. Jen: Access will not handle the i) security requirements, ii) number of users, iii) volume of data and transactions. (gave them a bunch of numbers here) IS: (long pause) Oh, how come you are developing this level of apps? Jen: I inherited some of them written in 4D on the Mac, I converted the first to a crossplatform (Mac/PC) VFP app when you forced us to switch to PCs. IS: We didn't support 4D. Jen: I know........
Here are some strengths and weaknesses which quickly come to mind:
Access strengths:
Fox is great if you've got at least your own framework. You've sat down and put in the hard, up front work. There's nothing like putting an app together if you've got the classes put together already--like Access. But unlike Access, you can change your own classes. It's a great candidate for applications more complicated than basic.
My favorite is still Fox.... [and] My boss likes Access. -- Steve Miller
There is no comparison between the access speeds of VFP and VB. VFP is light years faster on every operation, even with largest data sets and VB using the fastest RDO statements. The only reason we program in VB/ODBC is because some of our clients are a little uncomfortable with VFP and prefer a more "mainstream" solution such as VB/SQL-Server. -- Russell Sturm
Our top management is delighted with the features, performance, and look/feel of our products. However, at the same time, they have little appreciation for function when it clashes with being "politically correct" in the marketplace... and they don't have the technical expertise to understand, when considering our products' requirements, that VFP is probably the best and perhaps only way to get there.....
By the way, I know that when compared to earlier versions of Jet, there was no comparison... Jet simply sucked when matched against VFP. Also, from what I've read, it seems that Jet imposes some show-stopping obstacles when it comes to supporting read/write cursors derived from SQL pass-through queries and the like.
For example, in VFP it's very simple and extremely fast to do a couple of queries, then create an index on each cursor and relate the resultant cursors on a common index expression (not necessarily related on a static field, but rather related on an expression... very important!), and one can even make the cursors read-write by exercising a USE AGAIN command on the cursors. One can then "walk the indices" of these two (or more) "related" cursors and do all kinds of wonderful analytics, manipulations, and lookups nearly instantaneously. Then, with only one additional statement, one can flip any records of interest into a permanent table or export them into an Excel file, etc. This is nirvana for us insofar as meeting our needs. -- Mark S. Frank
As for the rumormongering, surely by now most of us can see that it is only and exactly that - a rumor of the first order! There is not one shred of evidence to support any such conclusion. Some nervous nellies associate lack of advertising with proof of demise. That's a poor yardstick to use for such a major conclusion!
As for the visibility of Access vs VFP, that is a problem, but only in the way that one sees more Chevies than one sees Mercedes'. Should we all run out and buy Chevies because everyone seems to be driving them??? For years VFP has had no peer when it comes to data manipulation speed and flexibility. Yes, it is decidedly not easy to learn/use, but once you have "paid the price" (gone through the learning curve) it is the best. VFP also has much much larger capacities than Access, and this matters in countless applications.
I suppose that I am "preaching to the converted" but I do think it's worth raising these kinds of issues with the decision-maker who wants to be "politically correct". Probably the most succinct answer I could offer is "since VFP is the best tool for this job, it is the politically correct choice! -- Jim Nelson
I have had it up to 400,000 records so far for testing and VFP is able to find all occurrences of a telephone number in less than a second. And I'm running this on a 486/33DX, Windows 3.11, and 16 Meg of RAM. So I believe that VFP will serve the purpose nicely. -- Bill Chadbourne
[Editor's note: This section includes some excerpts from the paper, which is dated November 1996, and is listed by written permission of the author]
To read the entire paper - point your browser to: http://premium.microsoft.com/msdn/library/bkgrnd/choosing.htm [Note: the above URL requires MSDN registration -- Editor]
The above URL provides a detailed comparison and thoughtful discussion of various issues surrounding this important choice. Here's the list of contents:
To see just the appendix titled "Visual Tool Features Comparison" in chart form, go to: http://premium.microsoft.com/msdn/library/bkgrnd/choosing.htm#choosappendd [Note: the above URL requires MSDN registration - Editor]
For those without Internet connections, the chart is presented here (it is not a copy -- it is a representation of the same data) [and is reproduced here by written permission of the author - Editor].
[Microsoft] Note This comparison is not an exhaustive list of the features of each product. Its intention is to highlight some of the similarities and differences between the Visual Tools. For more information, see the sources listed at http://premium.microsoft.com/msdn/library/bkgrnd/choosing.htm#choosappendd [Note: the above URL requires MSDN registration -- Editor]
[Microsoft] Note: This comparison is not an exhaustive list of the features of each database engine. Its intention is to highlight some of the similarities and differences between the engines. For more information, see the sources listed in the full article at http://premium.microsoft.com/msdn/library/bkgrnd/choosing.htm#choosappendd [Note: the above URL requires MSDN registration -- Editor]
George Goley's Comparison paper: "What is the best MS tool for development?"
[Note from Editor: Mr. Goley's paper (below) is listed by permission]
[This section was provided by Evan Delay, from a message posted to CompuServe in January 1996. As Evan says "Although the info is getting a bit dated, it is still quite relevant" -- Editor]
For more information about Mr. Goley and Micro Endeavors, Inc. (MEI): http://www.microendeavors.com
MS offers 5 development tools that can be used in conjunction to create a variety of inter-operable business applications. When called upon by Microsoft sales office to meet with large clients, among the first questions asked is, "what is the best MS tool for development"? Since Micro Endeavors is an outside firm, and since Microsoft is more or less requested to say "It depends, they're all good", MS clients place great store in MEI's opinions.
Clients and MS sales reps are both looking for simple answers to what is an obviously complex question. Our response is to list the 5 development products, identifying how each can/should be used to develop business applications. These lists are designed to present the 5 tools as an "integrated" set of tools that can work together to produce enterprise-wide business solutions.
Here is the list:
Access:
After reading over the material presented here, spending time on it, and shaping it for presentation, I have become convinced that I'm glad that I am a FoxPro programmer, rather than an Access programmer.
I feel like I'm driving a Lear Jet rather than a Cessna. Both of them can do some similar things, but the Lear Jet might do them more quickly, more elegantly, and more powerfully. And more luxuriously.
But, I guess both of them can bring enjoyment. I just want my passengers to have the most enjoyment I can provide them!!!