Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Articles
Search: 

How does MS Access compare with Visual FoxPro?
Tom Hayward, January 1, 2001
As a long time "traditional" FoxPro programmer finding myself in the middle of learning Visual FoxPro 5.0, I have watched topics pop up which sometimes launch many people into sort of a frustrated attempt to lay out some arguments quickly into a sort of helpful response. One of these topics is th...
As a long time "traditional" FoxPro programmer finding myself in the middle of learning Visual FoxPro 5.0, I have watched topics pop up which sometimes launch many people into sort of a frustrated attempt to lay out some arguments quickly into a sort of helpful response.

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:

  • I have gathered all of the comments I could find going back about 6 -7 months.
  • I have boiled everything down as small as possible without losing any points of comparison.
  • I have taken some liberties in paraphrasing wording -- with the goal of brevity and clarity uppermost.
  • When an ellipsis (e.g.....) is used, it indicates some words are missing (which are not relevant to the comparison).
  • When square brackets [such as these], they indicate words were edited to make the grammar fit the remaining words.
  • I have made it a priority to attribute each comment to the "author" or person who contributed.
  • If I have overlooked anyone or made a mistake, I ask that you let me know so that I may correct it.

MS Access versus MS Visual FoxPro -- Which One, and Why?
  1. A list of comparison highlights between Access and Visual FoxPro
  2. Comments gathered from Universal Thread (no particular order)
  3. A chart from (and pointers to) an appendix from a white paper called "Visual Tool Features Comparison" on the Microsoft Internet site.
  4. George Goley's Comparison paper: "What is the best MS tool for development?"
Comparison Highlights between Access and Visual FoxPro

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:

  1. Learning VFP will put you years ahead in terms of being able to adjust to OOP/OOA/OOD in comparison to only using VB. VFP has good PEM functions, a class browser, and can handle multiple class libraries. VB has no class browser, no class libraries, and can't subclass. If some future version of VB does contain these, you will know enough to be able to use it before it's ever released.

  2. As a client/server development tool, VFP is easier, more problem oriented, more capable, offers better cursor and connection control, and has native SQL.

  3. The DBC is more stable and capable than the MDB. It can be logically divided among network drives and doesn't suffer from MDB compacting requirements.
There are a number of common myths about VFP. Here are some of them debunked:
  1. VFP based on the outdated xBase language as opposed to Visual Basic which is very modern.

    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.

  2. VFP is for legacy programmers.

    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.

  3. VFP is slower than Visual Basic

    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).

  4. Microsoft does not support VFP.

    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".

  5. VFP is not truly a relational client/server tool.

    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.

  6. "We have to decide whether to use VB and Access/VBA or to use VFP."

    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

Comments
  1. ... not only [is] Visual FoxPro .... more powerful than Access but also .... Access is bundled in MS Office as an end user tool while Visual FoxPro is bundled in Visual Studio as a professional developer tool. -- Michel Fournier

  2. ... yesterday, I got a call from a client. "Hey, Michel, we just did an Access application and our investment was not worth it. When we ran it over this million record table, Access just started crawling down. What will be involved in time and money in order to redo that in Visual FoxPro?" -- Michel Fournier

  3. It's not necessarily "better", just different. Think of it this way (the way Microsoft itself categorizes these products): Access is part of Microsoft Office, used by end-users. Visual FoxPro is part of Visual Studio, used by developers. -- Colin Keeler

  4. Exactly!!! The major problem with users though is conveying to them the benefits of an app written in VFP over Access, i.e. speed, robustness, features, etc. A lot of users assume that since Microsoft includes Access in Office that it must be the best choice. Generally speaking, if a user wants to make their own simple screens, reports, etc., they should use Access. If the user wants you to develop a system for them -- use VFP. And if they want access to files they've already created in Access -- ODBC. -- Colin Magee

  5. Access is a great business tool for a non-developer for developing a simple database. The problems with it are simple:
    1. One file (MDB) is the whole shebang: data, forms, queries, reports. It gets corrupted and [you're out of] luck.
    2. If you're at all accustomed to the power and flexibility of VFP, you'll soon be tearing your hair out and saying "I don't get it, this is EASY in FoxPro!"
    3. Its search engine is slow. I mean, really, really slow.
    On the other hand:
    1. Just about anyone can create reports, forms, and queries in Access without risking serious damage to data. Everything is point and click, virtually no programming, at least with code.
    2. Access is more 'seamless' with the other Office applications, (97, anyway. previous versions were kind of cranky)
    3. Development is quick. It's hard to create a bug, (but not impossible). I still hate it, but I'm sure one of these days, I'll need it for something.
    -- Matt McDonnell

  6. [Briefly], Access has two major setbacks:
    1. Chokes in multi-user mode when more than 30-40K records in a table.
    2. Very limited from programming standpoint (limited set of function/commands, etc.)
    Basically, as stated by MS, Access is End-User Tool, and VFP is Developer Tool. -- Edward Pikman

  7. I have had [to] re-write ACCESS programs that couldn't manage to handle the expected workload. One of them was a client who had hired the ACCESS programmers "Because they tell me this will just be cut and paste and they'll have it ready in 2 weeks". They're now using my VFP5 program, after spending [several] months and [quite a lot of money on programming in] ACCESS. People ARE learning what VFP can do, they're just slow to change. That's human nature. -- Barbara Paltiel

  8. Consider the following:
      Microsoft Office is for users.
      Microsoft Visual Studio is for application development.

      Microsoft Access is part of Office
      Microsoft Visual FoxPro is part of Visual Studio.

    'nuff said. -- Bryan Jackson

  9. Additional arguments:
    1. VFP distribution is more robust than Access.
    2. Note the number of professional applications that have been written in each. VFP is a clear winner here.
    3. If the app is a simple one, Access development will be faster.
    4. Access has no classes. It is not an object-oriented language.
    5. The aftermarket for VFP is wider.
    6. If performance is an issue, VFP is the winner by a long shot.
    In summary, Access is basically (g) an end-user tool, albeit a powerful one.

    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

  10. Just to add my 2 cents worth. A couple of years ago, I was seriously questioning the time I knew that I'd have to invest to learn 3.0 when it came out. If you think the rumors are bad now, then they were worse. Although we all may not be overly happy at M$ for their apparent lack of effort with VFP, I think that we as VFP developers are on far firmer ground today. I believe that it was [in a] commentary about DevCon that stated that there are companies out there having problems with PowerBuilder and Delphi apps and are looking again at FoxPro as a viable solution.

    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

  11. I've recently switched from developing in MS Access to MS Visual FoxPro 5.0. I'm very happy with what I've seen so far, but I've got one situation where FoxPro seems to have a weakness when compared to Access. I am trying to write a cross tab query to total hours used by account for employees and managers. I would like the output of my query to look like this:
    				 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
    This would require Account to be the column header, sum (usage) to be the data, and Manager and Employee to be the row specifiers. Access has no problem with this but FoxPro's query designer won't let me put more than one item in the row specifier box. I'm very happy with FoxPro so far but why is it that Access has this feature and FoxPro does not? Am I missing something? -- Brian Hartin

    You can go around the [above] problem by running the query in two steps:

    1. You create view/cursor combining two fields Manager, Employee into one.
    2. You run cross-tab query having new field as row identifier.
    -- Edward Pikman

  12. ....does anyone else get bleedin' tired of having to deal with people who: 1) don't know Fox and 2) haven't attempted to learn Fox yet think they can tell everyone what's wrong with Fox? If I hear one more contractor/consultant make the statement "Fox is ok to use until you decide to move the system into a REAL database" I'm gonna hurt something! And the gods help us if we didn't hire these people to do a project in Fox! -- Dorris Beaird

  13. Add this [story]....

    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........
    I'm getting the portables. The IS "help" desk tech is still breathing -- Jen Ceurvals

  14. I have developed applications with the latest version of both. I feel VFP is superior from a developer's point of view. I also feel each has strengths over the other. End users like Access because of 1) marketing and 2) marketing. :-)

    Here are some strengths and weaknesses which quickly come to mind:

    Access strengths:

    • Query by form is inherent in forms' functionality
    • Less resource intensive during run time
    • Seems more durable during run time
    • Functions related to form's objects can be seen all at once
    • Exports to HTML, IDC, and ASP inherently (crudely)
    • Accepted by end user more readily (probably because it is included in a software suite)
    Access weaknesses:
    • Methodology limits experienced developers
    • Restricts creativity in creating solutions for end users
    • Major idiosyncrasies for developers (forced to learn to do things in complicated time consuming manners)
    • Properties do not appear alphabetically in properties window
    • Cannot change file structures of tables with data as easily as VFP
    • Relies on Visual Basic and Data Access Object for custom development and data access
    • Reach developmental threshold quicker (less creativity can be used)
    • Can only open one project at a time
    • Apps take just as long to develop as VFP but end user expects a quick turn around because of marketing ploys
    • Menus are harder than VFP menus to work with
    • Object syntax reference is unclear (! vs. .)
    VFP strengths
    • More control for the developer
    • True object oriented development with classes
    • Visual classes
    • Quicker app development time once a methodology is laid out
    • Quicker data access
    VFP weaknesses
    • Resource intensive during run time
    -- Richard Druckenmiller

  15. You forgot to say that Access will just not work for multi-user high-volume data application. -- Edward Pikman

  16. I've done Fox since '89, and I have a year of Access 2 (not 95/97/whatever is next). With that background, I say that Access 2 is actually a decent language for small applications. Things snap together very quickly. But give it something it wasn't designed to do, and it gets frustrating.

    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

  17. Keep in mind that Access uses the Jet database engine. VFP has its own engine..

  18. Comparison follows between MS Visual Basic and Visual FoxPro

    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

  19. Access hits the wall at about 30,000 records. So if they plan to have anymore then that they will find the speed (or should I say the slow?) unbearable. Access is designed for very small low impact databases, not for larger robust systems. -- Ed Crawford

    1. VFP's imminent demise is all rumor, apparently generated by both the mis-informed and those pushing other products. DEVCON 97 and the ongoing build of version 6 (even though many of us want to see 5.x working right first) should be proof enough.
    2. You know VFP. Do you know Access? Would they expect to get someone else, or are they ready to risk this app with you as your "version 0 [zero]" Access app?
    3. Is there any volume to the data to be processed? If so, Access may have capacity problems. VFP has loads more capacity than Access.
    4. Are there reasonably tight speed requirements? VFP is still the fastest on the planet (when done carefully and right, as I assume you know how to do).
    5. VFP is at least (guesswork here, but what the hey!) as capable as Access for OLE. Probably more so (since I don't know what "automation" capabilities Access has).
    -- Jim Nelson

  20. My company has developed some products in VFP that serve as analytical, decision-support tools for healthcare professionals. By necessity, these apps interactively crunch LOTS of data. Rather than dealing with the needs imposed on a typical client-server transaction-processing application, our applications instead demand very fast, complex, multi-table analytical operations in which VFP seems to really excel.

    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

  21. By "politically correct" I suppose that you mean that VFP is only rarely seen anywhere whereas Access is everywhere. It may also be related to the "problem" that the imminent demise of VFP has been prognosticated by a few for a very long time now (but, I remind you, nowhere near as long as the demise of COBOL has been predicted).

    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

  22. My workplace is a telemarketing center. We use a UNIX-based dialer that downloads its files to Excel. I want to be able to analyze the transaction files (these are the 200,000 record files). These transaction files are further drilled down to another (much smaller) file for analysis. After this drill down, the transaction file is used solely for telephone number lookup.

    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

A chart from (and pointers to) an appendix from a white paper called "Choosing the Appropriate Database Development Tool" on the Microsoft Internet site. (see following URL address)

[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:

  • Choosing the Appropriate Database Development Tool
      by Robert Green
      Product Manager for Desktop Databases
      Microsoft Corporation
      November 1996
  • Contents
    • Introduction
    • Database Tools Overview
    • Q&A
    • Web Issues
    • Pure HTML Solutions
    • Extended Network Solutions
    • ActiveX Document Solutions
    • Conclusion
    • Appendix A: Microsoft Internet Technologies and Tools
    • Appendix B: Microsoft Data Access Technologies
    • Appendix C: Glossary
    • Appendix D: Visual Tool Features Comparisons
"This is an excellent document outlining the strengths of each of Microsoft's Database Development Tools." -- Al Williams

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]

Visual Tool Features Comparison
FeatureIncluded in Microsoft Tool
AccessVBVFP
Cross platform support

X
Full complement of object based design toolsXXX
Drag-and-drop to set relationships between tablesX
X
Highest number of ease of use featuresX

Table, Form, Report, and Query WizardsX
X
Import WizardX
X
Upsizing WizardX
X
Create SDI and MDI forms
XX
Drag-and-drop fields onto formsX
X
Field mapping to specify type of control or class used when field is dropped onto form

X
Updateable query result setsXXX
Color coded editorXXX
Debugger includes Locals, Watch, Call Stack windowXXX
Watch values in debuggingXXX
Debugger settings can be saved for later use

X
Best visual integration with Microsoft OfficeX

Programmatic integration with Microsoft OfficeXXX
Excellent support for ActiveX controlsXXX
Support for ActiveX controls that act as containers
XX
Support for ActiveX controls that bind to a row of dataXXX
Spport for ActiveX controls that bind to multiple rows of data
X
Vtable binding for improved ActiveX control performance

X
Early binding in code for improved Automation server performanceXX
Can control other Automation serversXXX
Can be called natively as an Automation serverX
X
Can create custom Automation server
XX
Remote Automation support
XX
Component Manager to manage Automation servers
X
Internet wizardX
X
Object BrowserXX
Integration with Visual SourceSafe (Access requires Microsoft Office 97, Developer Edition for VSS)XXX
Full support for object oriented programming, including inheritance and subclassing

X
Object programming through class modulesXX
Create reusable codeXXX
Create reusable interface elements

X
Subclass ActiveX controls

X
Event tracking tool

X
Coverage logging tool
XX
Code profiling tool
XX

[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]

Database Engine Features Comparison
FeatureIncluded in Microsoft Engine
JetFoxProSQL server
Heterogeneous joinsXX
Rushmore query optimizationXX
Top n and top n% queriesXX
Validation rulesXXX
Validation rules can be custom code
X
Default valuesXXX
Default values can be custom code
X
Triggers and stored procedures
XX
Referential integrity through triggers
XX
Declarative referential integrityX
X
Engine level cascading updates and deletesX

Basic locking unitPageRowPage
Row locking on insertXXX
Row locking on update and delete
X
Table-level replicationXXX
Row-level replicationXXX
Field-level replication
XX
Custom code for replication conflict resolutionXXX
Scheduled replication (Jet engine requires the Microsoft Office 97, Developer Edition)X
X
Replication over the InternetX

Built-in securityX
X
Built-in encryptionX
X
Transaction processingXXX
Distributed transactions

X
Dynamic backup and restore

X
Back up and restore a single table

X
Transaction log backups

X
Automatic recovery

X
32-bit engineXXX
Data capacity1.2 GB per database2.1 GB per table1 terabyte per database
Maximum number of users255Unlimited connections32,767
Hyperlink data typeX

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:

    Features:
    1. Best Report Writer
    2. Easiest for non-professionals to use
    Best Uses:
    1. Report and Ad-Hoc Query writer for end-users to VFP, VB and Access
    2. Creation of "personal" applications managing local data, often by power users
Visual Basic:
    Features:
    1. Smallest footprint of high-level languages
    2. Can create OLE objects
    3. Excellent OLE integration
    Best Uses:
    1. Creation of non-data intensive business apps
    2. Creation of modest-sized client/server apps
    3. Creation of small-footprint apps
    4. Create of OLE controls for inclusion in VFP apps
    5. Creation of non-data intensive Office Automation apps using Office
Visual C++:
    Features:
    1. Greatest performance
    2. Best control of low-level functionality
    Best Uses:
    1. Create OCX's and DLLs that can be used in VFP, VB and Access applications
    2. Create commercial, non-data oriented applications
SQL Server:
    Features:
    1. Data security
    2. Robust transactions
    3. Automatic data replication
    4. Good transaction performance
    Best Uses:
    1. Data source for line-of-business VFP apps, smaller VB apps, ad-hoc Access users
    2. High-volume transaction oriented applications
    3. Storage of sensitive information
    4. Data source for WAN-based applications
Visual Foxpro:
    Features:
    1. Only high-level language with Inheritance, Polymorphism, Encapsulation. (OOP support for high-maintainability, and rapid application development)
    2. Fastest local data engine (query speed actually exceeds SQL Server in most common operations)
    3. Best data manipulation language (seamless integration of Xbase and SQL)
    4. Excellent ODBC and OLE support
    5. Ability to write apps that seamlessly utilize either local or remote date (allows user to start with file/server and upsize to client/server if needed)
    Best Uses:
    1. Creation of enterprise-wide, client/server, line-of-business applications (takes advantage of OOP, performance and optional local data storage)
    2. Creation of Data Warehouses that combine SQL Server's transaction processing and security with VFP's superior query speed, flexibility, and local data storage
    3. Creation of departmental, client/server or file server based, line-of-business apps
    4. Creation of Decision Support Systems using client/server or file/server back-ends.
    5. Database oriented office automation projects that utilize Microsoft Office.
If the client needs it summarized even further, it goes like this:
    Access for ad-hoc reporting and personal apps.
    VC++ to build OCXs.
    VB for small footprint, and non-data intensive apps.
    SQL Server for sensitive, WAN and high-transaction apps.
    VFP for line-of-business applications
The MS sales rep can sell all 5 products to a client with the following pitch:
    Use VFP as the core language for business app building.
    Use VC++ to build OCXs to use in VFP and VB apps.
    Use Access as an ad-hoc report writer for endusers.
    Let end-users use Access or VFP for their own, personal apps.
    Use SQL Server as a back-end to VFP and VB applications.
    Use VB for non-data intensive, small footprint, distributed apps.
To use an example, at Micro Endeavors, our new office systems will include:
  1. Seminar tracking system written in VFP, using SQL server and DBFs for data storage
  2. Pop-up timesheet program for developers written in VB, using SQL server as the back-end.
  3. Sophisticated project management, estimating and timesheet tracking system written in VFP, using SQL server and DBFs for data storage
  4. Ad-hoc reporting of all of this info using VFP and Access95.
  5. Enhanced graphing and communications using DLLs and OCXs written in VC++.
Conclusions

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!!!

Tom Hayward, Hayward Interaction
Tom Hayward is a Visual FoxPro Programmer who started using FoxBase in 1990 for an accounting firm, and continued using all the subsequent versions with clients in a variety of industries in Illinois, Georgia, Nebraska, and Wisconsin, including collections, medical, mortgage, title insurance, commodity trading, defense, government, credit union, and manufacturing. Tom was born in India of missionary parents and grew up in South Africa before attending Northern Illinois University.
More articles from this author
Tom Hayward, February 1, 2006
This article discusses an improvement for the Grid control, called the Hayward LightSpeed MultiSelect Grid method, which provides a new way to offer multiselect capability for your applications.
Tom Hayward, September 1, 2001
What can I possibly offer the UT community in these few paragraphs? "Remain Persistent With Your Programming, And You Will Reach Your Dreams"? Well, what's wrong with that? I know it happened to me..... I still remember the mystery and curiosity that suddenly swirled through my head at a party...