Unable to load SSI head
Software Review - FoxPro for Windows Version 2.6
by Terry R. Blankenship, Feb 1995
Topics include:
- Features
- Communication with the HP 3000
- Database
- Screen Builder
- Report Writer
- RQBE: Relational Query By Example
- Menu Builder
- Project Manager
- User Friendliness
- Performance
- Documentation and Support
- Summary
- At-a-Glance
I have used Foxbase since 1987 to develop applications that I judged would not
be appropriate on our HP 3000. Foxbase then turned into FoxPro (DOS) two years
later. Then a Windows version was released circa 1991. I was thrilled to be
able to develop Windows-based applications. I wrote incremental search
routines, where you type a letter in a pick list and the list progressively and
dynamically adjusts to your search target. I wrote reports that could execute
macros as part of field definitions. I could do anything. Then I got on the HP
3000 and used QUIZ or QUICK. Although I had used these fine languages for 13
years, they paled alongside FoxPro for Windows.
I thought how neat it would be if FoxPro for Windows could read and write data
in my TurboIMAGE database. It would be the best of both worlds, I told myself.
The PC would do what it does best--presentation. The minicomputer would do what
it does best--reliable data storing. If only the gap could be bridged. I
certainly did not want to drop-kick my HP 3000 out the door. It had been far
too reliable to the company.
Well, with the advent of IMAGE/SQL and ODBC support gaining widespread
acceptance, I was excited to learn that my application development dream had
become reality... for the most part. Version 2.6 of FoxPro for Windows was the
first version to provide ODBC support. I wanted to review it to determine its:
- ease of use
- speed when it went against IMAGE/SQL databases
- practicality for developing applications
Of the many aspects of
FoxPro for Windows, I want to say up-front that I cannot cover all but hope to
review only the main ones. The environment in which I operate is a Novell 3.11
network running Ethernet 10 Base T. The client is a Windows-based 486 running a
dual stack with IPX and TCP/IP. I run Reflection on the client. The HP 3000 is
a 949 running MPE/iX 4.0, connected to the network through a ThinLAN card and a
dedicated hub so that access to the minicomputer is assured if the LAN server
goes down. MPE/iX 4.0 had to be patched to provide ODBC support.
FoxPro for Windows is a DBMS with bundled development tools like a screen
builder, report writer, menu builder, etc. It has a native relational database
that you can use quite successfully. Presently it does not have a data
dictionary, which many feel severely limits it as an enterprise-wide software
platform. Actually, when you send SQL statements to the HP 3000, the results
are placed in this native database format, or table, as I shall refer to it.
To communicate with IMAGE/SQL through FoxPro for Windows, you first have to
prepare the IMAGE/SQL environment by running SQL on the HP 3000.
There is initial setup to be done on that end that I will not go into here.
Suffice it to say that it is simultaneously easy and difficult. Easy, because
once you have done it, it doesn't seem so hard. Difficult, because
documentation on the HP side and the Response Center side is cryptic,
inaccurate, and disorganized. And that is the good side.
Once you have installed the ALLBASE/SQL ODBC driver in Windows (which is not
hard, yet I won't describe it here), you have to issue the FoxPro for Windows
command "SET LIBRARY TO FPSQL." This makes available a library of functions
(distributed in the Connectivity Kit portion of FoxPro for Windows diskettes)
for communicating with the ODBC driver. I wanted initially to connect with my
IMAGE/SQL files on the HP 3000, so I issued the command
handle=DbConnect("","","","DSN=SVMDBE;USE=;PWD=")
"Handle"
is a variable (could be any name) that contains the numeric result reflecting
the success or failure of the command. Handle equaled 1, which indicated a
successful operation. I had connected! The first time I did this, I felt like
popping a bottle of champagne. Many of my previous attempts had been trial and
error, yielding a result code of -1, which is very bad.
DbConnect is one of the functions provided by the connectivity library. I next
wanted to see which tables I had connected with. I issued the command
handle=DbTables(handle,"'VIEW','TABLE'","TBLSVM")
This command places the results in a table named TBLSVM (see Figure 1). So far
so good. Yet I wanted to look at some data in the IMAGE/SQL tables. You do this by
transmitting an SQL statement through the DbExec function to the HP 3000; the
resultant data is placed in either a cursor (a temporary table on your PC) or a
table (a permanent table on your PC). I issued the following command to
retrieve a customer record by account number:
retcode=DbExec(HANDLE,"SELECT * FROM DBSVM.ACCOUNT_MASTER WHERE
ACCOUNT_NO = '000044'","T")
In subsecond time, I had my data on my PC, placed in a table called "T." Blazing
fast on an indexed lookup. Although I had heard that the ODBC approach had
severe performance problems, I did not experience any. Whenever I did a SELECT
in which there were nonoptimized relations with entire tables having to be
passed and re-passed, I had to wait 30 minutes or more for the result. That
was, of course, more than I would have waited if I were in QUIZ, for example,
straight on the HP 3000. I have never visualized ODBC usage in any way other
than keyed lookups, although there are exceptions.
FoxPro for Windows has the INSERT and SELECT SQL commands available in Version
2.6 while support for the UPDATE and DELETE commands is available in Version
3.0 (which will have been released by the time you read this.) Obviously, not
having the UPDATE and DELETE commands available compromises what you can do.
All in all, though, I was very pleased with the way FoxPro for Windows handled
its ODBC interface to my HP 3000. It was reliable. Never failed. But there are
few guideposts, and a good deal of trial and error was my tutorial. In fact,
someone needs to put together a tutorial detailing how all the different parts
work.
FoxPro for Windows has its own native table structure. This is where the
results of an SQL query are placed. (Figure 2 shows the database structure.)
Creating one is as simple as naming field names, determining data types, and
deciding field lengths. It also is extremely simple to change a database. I
don't know about you, but I it find time-consuming to change database
structures. And you have to unload, then reload, data. But in FoxPro for
Windows, you simply make the changes; you are then asked if you want them to be
permanent. If you answer yes, the changes are applied immediately.
Figure 2: Windows FoxPro table structure
FoxPro for Windows has long had the reputation of being the fastest PC database
around, due mainly to advanced indexing algorithms. Called Rushmore technology,
it makes performance in FoxPro for Windows nothing short of astounding.
Establishing indexes is quite simple and very versatile. (See Figure 3
for an example.)
Figure 3: Creating an Index
A word about the types of data you can store in a FoxPro for Windows database:
Although numeric and alphabetic data are passed from the HP 3000, the database
can also hold memo data--basically entire documents, if you want. It can also
hold pictures, i.e., BMP files, TIF files, etc. Human Resources can scan in an
employee's picture for the department's records, and then view it on the screen.
FoxPro for Windows has the slickest screen builder I have seen. (Figure 4
illustrates a sample screen under construction.) You define objects, then give
properties to the objects (see Figure 5).
You can use a screen wizard that
suggests how a screen might look, and then modify it. Available too are all the
acoutrements that you love in Windows applications. Push buttons, radio
buttons, spinners, invisible buttons, check boxes, file-based pick lists,
pop-ups, thermometers...all are here. And they are all fairly easy to put
together and run with. Remember too that they can be brought to bear on your
IMAGE/SQL data. These screen presentation techniques provide a quantum leap
forward for user friendliness.
Figure 4: Screen Builder
Figure 5: Define Object Properties
The approach to designing a report is to access a database and run selected
records through a report definition file you have set up. Setting up a report
in FoxPro for Windows is straightforward and pretty much WYSIWYG. You can see
the report taking shape in front of you. (See Figure 6
for an example of the screen layout.) Some Windows-based front-end report
writers for the HP 3000 do the same thing.
I found nothing I could not do in FoxPro for Windows' report writer. It really
is not fair to compare it to QUIZ, because QUIZ has platform constraints that
FoxPro for Windows does not have. The two are simply not comparable. Think of
Michael Jordan playing one-on-one basketball with me. Not even close.
Report wizards are available for you to lay out a report initially. You then
modify the report to get what you want. The report wizards speed up the process
in many cases, but, in others, are only a hindrance.
FoxPro for Windows gives both the casual and sophisticated user a robust query
tool. (See Figure 7
for the layout of an RQBE exercise.) Once your data
returns from the HP 3000 and is placed in either a cursor or a table, you have
the ability to select records, summarize data, and produce complex reports on
the run. You are helped every step of the way. Once you construct a query, you
can save it and run it again with different parameters. A neat feature of RQBE
is that you can push the "See SQL" button after you construct a query and see
the actual SQL statement that is generated. This is a good way to learn about
putting together SQL statements.
Windows' applications are usually driven through a pull-down menu that may
bring forward another menu or dialogue box. FoxPro for Windows gives the
developer excellent tools to craft a wide variety of menus to control and
navigate through an application. You have the ability to demo what your menu
will look like while you put it together.
Programs, screens, menus, reports, etc., are all put together inside a project
manager. This is an immensely helpful method of organizing a project.
(Figure 8
gives you an idea of what the project manager looks like.) Once you have
assembled, written, and tested all your code, you compile the entire project
into an "application," which is an .APP file. You then execute the application
(i.e., DO NEWPROG.APP).
Figure 8: Project Manager
The use of wizards in FoxPro for Windows builds in a great deal of assistance
in a user-friendly way. The GUI approach to application development makes
putting together even complex applications a lot easier than the traditional
command-oriented method. Super online help gives you the answer to just about
any syntactical question you might have.
Using the different tools takes some getting used to, but I found the learning
curve far from daunting. FoxPro for Windows does not, however, have an online
tutorial; this would be helpful.
Use of the ODBC interface in Windows has gotten a bad rap from some people.
Performance is supposed to be atrocious. While this may be true for some, it
simply wasn't true for me. Keep in mind that I am partial to using indexed
lookups on the HP 3000. Yet, even when doing a sequential chained read looking
for a record that satisfied certain conditions, I found the performance to be
subsecond. You and I both know that performance is influenced by many
variables. So, draw your own conclusions.
Using the FoxPro for Windows native PC database yields incredible speed, i.e.,
reading more than 40,000 records in two seconds. Whether your query takes
advantage of Rushmore technology influences performance. Yet my interest in
FoxPro for Windows is mainly in its potential as a front end for IMAGE/SQL.
Microsoft has provided world-class documentation for FoxPro for Windows. The
documentation is clear and contains an abundance of examples. Microsoft also
staffs a full-service forum on CompuServe, which is invaluable for resolving
questions and distributing patches. GO FOXFORUM is your key to accessing it.
There are a number of factors to consider when you evaluate application
development packages on LANs. Although FoxPro for Windows has many pluses, it
has its share of minuses. It was exciting to see my IMAGE/SQL data returned for
me to manipulate on my PC through Microsoft's ODBC implementation. My
enthusiasm, however, is dampened because not all SQL statements are supported
in this version of FoxPro for Windows. That will be corrected, I'm sure.
Many people believe that FoxPro for Windows will never be heavy-duty enough for
enterprise-wide computing. They may be right. It may be more suited for
departmental computing. But I'm not sure I would rule it out as an
enterprise-wide development tool. If you are intrigued by the ODBC approach and
have LAN access to your HP 3000, give FoxPro for Windows a try. You will see
why it has attracted such a following.
Terry R. Blankenship is vice president of MIS for State Volunteer Mutual
Insurance Company in Brentwood, Tennessee.
FoxPro for Windows Version 2.6
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Price
$95 street price
$495 professional edition (includes Connectivity Kit)
Documentation
Language Reference
Developer's Guide
User's Guide
Getting Started
Connectivity Kit
Library Construction Kit
Unable to load SSI foot
