Bob Gallagher of PC Week Labs in their May 2, 1994 story states,
"...the Windows-based dBASE will fulfill the expectations of IS managers and developers ..."
"...it surpasses them (FoxPro and Clipper) with OOP (object-oriented programming) language extensions."
dBASE users can bring all their data, knowledge, and applications into the Windows environment and be immediately productive. If they would like to update their applications created with dBASE DOS using the visual design tools offered in dBASE for Windows, they can use the Component Builder™ to transform most of their existing DOS code into full Windows objects with automatically generated OOP code.
For end users, the Interactive Tutors™, FormExpert ™, on-line context-sensitive help, and visual design surfaces will get them up and running with dBASE in record time.
Extending the "English-like" dBASE language to SQL database servers is instantaneous, because all the same commands and design surfaces used against local data are applicable to remote data. When you are ready to upsize from local to SQL server data, you simply change the database connection. The applications are instantly scalable.
PowerBuilder does not have a native database engine. Users will be forced to learn Watcom SQL (which ships with the product) or to learn the dialect of another database server. dBASE users will not be able to leverage their knowledge of the dBASE language against SQL databases. PowerScript is also a non-standard language which lacks true object-oriented extensions.
End users will be forced to adjust to a user interface that is not fully CUA-compliant, and lacks Experts and Tutors. The updating of data is not automatic, and the data retrieval method is not what Windows database developers currently know (record-oriented). Finally, PowerBuilder lacks a mechanism with which to produce a code listing that shows all members of an object and their associated methods.
dBASE data (but not indexes) will be recognized by PowerBuilder after a conversion, but none of the code will be portable. Users basically have to start from scratch when creating applications with PowerBuilder.
So far, PowerSoft reports 25,000 licenses sold worldwide. This pales in comparison with more than 7.1 million dBASE users in the U.S. In 1994, InfoCorp estimates that there are more than 15 million dBASE users worldwide. This makes finding developers and training resources for dBASE much easier compared to PowerSoft.
Melinda-Carol Ballou of ComputerWorld in their July 11, 1994 article headlined "Access 2.0 hitting some snags" states,
"Microsoft Corp.'s Access 2.0 database appears to be causing corruption problems for certain users, according to a handful of developers who posted comments on CompuServe over the past month and interviews with other users....Also irritating to some is the fact that Access does not notify end users when data corruption has occurred. In those cases, users continue to enter data without knowing it has been corrupted. That work is then lost or rendered useless."
Access applications are a combination of recorded scripts/macros and Access Basic code.
Access Basic is only a subset of Visual Basic Applications Edition, and does not allow extensibility in the form of Visual Basic (.Visual BasicX) controls, Custom Controls, or OOP extensibility. Group development is also made difficult since Access stores all of its files in a single big binary (.MDB) file.
Finally, Access does not offer a unified database engine. It is impossible for a user to join databases of different formats in one single step. Users must go through a series of queries using ODBC and combine them manually in order to create a heterogeneous result.
Richard Finkelstein comments in the June/July 1994 edition of the Visual Basic Programmers Journal:
"..The database engine was not designed for Client/Server."
"..I tell all my clients it's (Access) a very very slow product- to keep their expectations low."
"..you'll need to be an expert programmer in order to fully access the power of its advanced features. It's the most difficult to use of the windows databases reviewed."
Karen Strauss
Windows Magazine
November, 1994
FoxPro 2.6 has added new Wizards, and a new Catalog window that attempts to mimic the Control Center in dBASE IV.® Also, FoxPro offers "Rushmore" technology allowing fast single user, simple index queries. However, the benefits end there. PC Week in their May 18, 1994 issue had an article which contained the headline:
"FoxPro 2.6 suffers from compatibility woes."
First, many of the new Wizards (forms and reports) are capable of only working on one table. This is not indicative of real world applications where multitable databases are the norm. Second, the Rushmore technology fails when relational joins and also multiuser access are factored into the equation. Again, these situations are more representative of real world applications.
FoxPro does not offer full compatibility with dBASE. It is an all-or-nothing deal. An organization has to move all dBASE users to FoxPro in order for one person to use this product.
Unlike dBASE for Windows, you cannot just run a dBASE DOS application unchanged. Their AutoMigrate feature is unable to translate dBASE objects into a Windows environment. Users should be aware that the resulting *.DBF's and indexes are no longer usable by other dBASE users. Additionally, PC Week states in its article:
"Much can go wrong with the AutoMigrate feature, and there is no printed documentation to turn to if it does."
Also, PC Week found in their testing:
"..turned up a surprising number of bugs, errors, and crashes involving these new features..."
Finally, FoxPro developers were publicly told on CompuServe by Microsoft that the company did not fix any bugs and instabilities between version 2.5 and 2.6. Furthermore, there have been many instances where Microsoft representatives have gone into FoxPro accounts and tried to convert them to Access. Microsoft's commitment to FoxPro appears very questionable.
However, Visual Basic does not offer a native database engine. Storage and management of data is accomplished through ODBC drivers. Rarely, if ever, has an add-on database engine outperformed a native engine in both performance and ease of use.
Visual Basic lacks interactive tools for visually querying data, providing source listings, Tutors or Experts, and a structured OOP language. It is obvious that it was not designed to be a database front end, but a quick prototyping environment when graphic flash, not data handling is the primary requirement. Also, Visual Basic does not have any language extensions to create custom controls that it can use. The combination of Visual Basic for basic development, ODBC for database access, and C for controls creation quickly becomes a difficult environment to manage.